fenfire-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Fenfire-dev] :-/


From: Benja Fallenstein
Subject: [Fenfire-dev] :-/
Date: Tue, 13 Jan 2004 08:53:46 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031221 Thunderbird/0.4

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Our paper has not been accepted to IPTPS'04. Below the reviews.
- -b



Review #63 For Paper #55

Attribute
Value


Your qualifications to review this paper
I know a lot about this area


Overall paper merit
Bottom 50% of submitted papers


What are the most important reasons to accept this paper? (the authors
will see this)
This paper proposes to store versioning information as first-class
objects in a P2P network.


Would this paper generate interesting discussions if accepted?
(the authors will see this)
Probably not.


Provide comments on the paper
(authors will see this)
The main ideas of the paper are (a) the notion of a "pointer record"
that can be used to link different versions of the document together;
and (b)a so called Storm abstraction.



Review #172 For Paper #55



Attribute
Value


Your qualifications to review this paper
I know nothing about this area


Overall paper merit
Bottom 50% of submitted papers


What are the most important reasons to accept this paper? (the authors
will see this)
The problem of versioning in a p2p web is a hard and interesting
~ one.


Would this paper generate interesting discussions if accepted?
(the authors will see this)
No, i don't believe it would. The proposal here adds little
~ to the OceanStore work. Many of the proposed enhancements
~ seem to be more a matter of software engineering than a
~ fundamentally different approach to the problem.


Provide comments on the paper
(authors will see this)
The need to search the entire P2P network for pointer records in
~ order to find the latest version of a document is really not
~ a scalable solution.

~ The authors claim that the main difference between pointers and
heartbeats in OceanStore is that heartbeats are "network
~ internal objects". This however, was never a goal of the
~ OceanStore work and seems a largely orthogonal issue.
~ Also, it would be nice to see a more detailed explanation
~ of the term "network internal object".

~ What is the access control mechanism used to allow only
~ authorized entities to perform updates?

~ The authors' primary objections to CFS is that documents
~ are destructively updated. This is more likely a design
~ decision by the authors rather than any fundamental limitation
~ of CFS.

~ While the proposal for a uniform data model to bridge multiple
~ content networks is a useful one, this again seems to be
~ largely a deployment and engineering issue. Why is the
~ proposed data model the right one?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFAA6QKUvR5J6wSKPMRAjqwAKDHQeVNWMQRa6C1pZ1VqqF7wpxuIwCeITcS
RGf7bEUfSMXuTTQGq7heNhM=
=4Ks7
-----END PGP SIGNATURE-----




reply via email to

[Prev in Thread] Current Thread [Next in Thread]