Thesis/Iptps02Feedback

We got rejected pretty bad. Based on the reviewer feedback, here are the things we need to do better next time:

- explain the problem and its relevance better.

- explain our solution and its originality better: I don't think for example that the authors understood at all the fact that the communities themselves were resources.

- give examples of application of our framework: the stamp example didn't cut it. We need an example where using U-P2P makes sense and solves a known problem, such as the difficulty of finding a design pattern or a component. This is what Neal is working on right now!

Aloke, are you back??? Your mini-thesis could be a great base for another paper. Next deadline: Feb 15th for the IEEE workshop on massively parallel systems.

Cheers,

Babak.

 Subject: 
	IPTPS'02 submission results
	Date: 
	Mon, 4 Feb 2002 17:01:31 -0600
  From: 
	IPTPS02 <iptps@cs.rice.edu>
	To: 
	babak@sce.carleton.ca
	CC: 
	IPTPS02 <iptps+notify@cs.rice.edu>

Dear Babak Esfandiari,

Thank you for submitting the following paper to IPTPS'02:

(157):U-P2P: a Peer-to-Peer Framework for Universal Resource Sharing and Discovery by Aloke Mukherjee, Babak Esfandiari, Neal Arthorne

Unfortunately, we were unable to accept your submission. We received a high number of submissions (99). The program committee had to make difficult decisions and ended up rejecting many submissions of high quality. Also, in the interest of maintaining an interactive workshop atmosphere, we were forced to limit attendance to 50 people. As a result, we had to limit invitations to authors of accepted position papers. We thank you for your interest and submission to IPTPS'02 and hope to see you at a future IPTPS!

Antony, Frans and Peter Contact email: iptps@rice.cs.edu

Review information (3 reviews).

Overall : Weak Reject Originality: Neutral Relevance : Weak Reject Technical : Neutral For each category the reviewer could choose from: (Strong Accept, Accept, Neutral, Reject, Strong Reject)

Comments for authors:

This paper is primarily an architecture document rather than a research or position paper. It presents a flexible and extensible way of phrasing queries, but it's unclear that it exposes a new problem, advocates a specific solution, or reports on actual experience.

It sets forth the architecture rather than describing design goals and tradeoffs.

Overall : Neutral Originality: Weak Reject Relevance : Accept Technical : Weak Reject For each category the reviewer could choose from: (Strong Accept, Accept, Neutral, Reject, Strong Reject)

Comments for authors:

Marginal. Frameworks are easy to propose. So what? Who's using it? But accept if room: let it make its pitch

Overall : Weak Reject Originality: Weak Reject Relevance : Neutral Technical : Weak Reject For each category the reviewer could choose from: (Strong Accept, Accept, Neutral, Reject, Strong Reject)

Comments for authors:

This paper describes a way of providing a generic sharing infrastructure for all sorts of documents - which uses an infrastructure such as Napster - and uses XML documents to encode metadata about the documents. It seems to me this is just a way of creating "community specific" interfaces for Napster like systems - described in XML.