/[gzz]/manuscripts/storm/article.rst
ViewVC logotype

Diff of /manuscripts/storm/article.rst

Parent Directory Parent Directory | Revision Log Revision Log | View Patch Patch

revision 1.137 by antont, Wed Feb 12 16:41:06 2003 UTC revision 1.138 by hemppah, Thu Feb 13 13:08:38 2003 UTC
# Line 486  and the characters retrieved from there Line 486  and the characters retrieved from there
486     documents-- or different versions of a document-- is only     documents-- or different versions of a document-- is only
487     stored once, in a block only referred to wherever     stored once, in a block only referred to wherever
488     the data is transcluded.     the data is transcluded.
489      
490    Our current implementation shows only links between documents
491    that are in memory at the same time [screenshot of xupdf, perhaps ref too
492    (submitted) antont: was thinking the same, it would illustrate this well].
493    In the future, we will implement a global distributed index at top of
494    a distributed hashtable, with the scroll blocks' ids as the keys.
495    To find the transclusions of a span, the system will retrieve
496    all transclusions of any span in the scroll block, then
497    sort out those that do not overlap the span in question.
498    
499    Since the problem is to search for overlapping ranges,
500    the spans cannot be used as hashtable keys. However, as the blocks
501    will be relatively small (limited by the amount of text
502    the user enters between two saves of a document), we hope
503    that this will not be a major scalability problem. Otherwise,
504    systems that allow range queries, such as skip graphs [ref],
505    skipnet [ref], may prove useful.
506    
507    One question raised by xanalogical storage is which links to show
508    for a popular document that has been linked to by many users.
509    We hope to address this problem by collaborative filtering
510    of links [explain, ref (grouplens.org pubs?)]. There has been research on
511    collaborative filtering in peer-to-peer systems
512    without compromising participants' privacy [ref John Canny].
513    For some purposes simple rules based on e.g. belonging to a group may be
514    applicable as well: e.g. when working on a project with a project group, it
515    may be beneficial for the members of the group to see other members'
516    comments of articles etc.
517    
518  4. Storm block storage  4. Storm block storage
519  ======================  ======================
# Line 1131  names, which is again outside the scope Line 1157  names, which is again outside the scope
1157     These public/private zones are an area where future research is needed,     These public/private zones are an area where future research is needed,
1158     possibly related to rights and permissions etc. too.     possibly related to rights and permissions etc. too.
1159        
1160     Comments may be new entities(?) linking to it       Comments may be new entities(?) linking to it
   
1161    
1162  7.2 Status, open issues and future work  [At the end of this section ? -Hermanni]
1163  -----------------------------------  When Xanalogical storage is not applied, using Storm as a
1164  Our current implementation shows only links between documents  replacement/equivalent of a conventional file and versioning system is
1165  that are in memory at the same time [screenshot of xupdf, perhaps ref too  trivial?    
 (submitted) antont: was thinking the same, it would illustrate this well].  
 In the future, we will implement a global distributed index at top of  
 a distributed hashtable, with the scroll blocks' ids as the keys.  
 To find the transclusions of a span, the system will retrieve  
 all transclusions of any span in the scroll block, then  
 sort out those that do not overlap the span in question.  
   
 Since the problem is to search for overlapping ranges,  
 the spans cannot be used as hashtable keys. However, as the blocks  
 will be relatively small (limited by the amount of text  
 the user enters between two saves of a document), we hope  
 that this will not be a major scalability problem. Otherwise,  
 systems that allow range queries, such as skip graphs [ref]  
 and skipnet [ref], may prove useful.  
   
 .. [how does video work here, i.e. are they huge blocks or collections of many  
    small, frames? or a sequence between two keyframes?]  
   
    Benja says: Probably large, but the number of links to them  
    still won't be that big, I guess. Not sure how to discuss this  
    in the text; feel free to propose something :-)  
1166    
    Toni: will try.. wondering also about who to consult :o  
1167    
1168  .. [This might be relevant also:  7.2 Status, open issues and future work
1169     http://www.hpl.hp.com/techreports/2002/HPL-2002-209.pdf  ---------------------------------------
    -Hermanni]  
1170    
 One question raised by xanalogical storage is which links to show  
 for a popular document that has been linked to by many users.  
 We hope to address this problem by collaborative filtering  
 of links [explain, ref (grouplens.org pubs?)]. There has been research on  
 collaborative filtering in peer-to-peer systems  
 without compromising participants' privacy [ref John Canny].  
 For some purposes simple rules based on e.g. belonging to a group may be  
 applicable as well: e.g. when working on a project with a project group, it  
 may be beneficial for the members of the group to see other members'  
 comments of articles etc.  
     
     
 Open issue: Tree hashing, also possibly needed for (OceanStore-like?)  
 distribution of shares  
1171    
1172  Open issue: We want to be able  [worth to mention, security in general ? -Hermanni]
1173    1) Open issue: We want to be able
1174  to copy the blocks from the NYT publication pool to our local computer  to copy the blocks from the NYT publication pool to our local computer
1175  and verify offline that it really comes from NYT. How to do this will go  and verify offline that it really comes from NYT. How to do this will go
1176  into the article as an open research question ;-)  into the article as an open research question ;-)
1177    
1178  Future directions: of course, we should implement a prototype  2) Open issue: identification of online entities ?
1179    
1180  Open issue/Future directions: implement multisource downloading  [worth to mention ? -Hermanni]
   
 Future directions: Implement home node model or directory model ?  
   
 Open issue: Firewall Transparency/NATs ?  
   
 Open issue: identification of online entities ?  
   
 Open issue: notes in the text about block sizes with video  
   
 Open issue: other related systems (within gzz?) for e.g. more synchronous  
 collabaration (irc?)?  
1181    
1182  .. moved the following here from intro, as suggested by (b&) Hermanni  .. moved the following here from intro, as suggested by (b&) Hermanni
1183    
# Line 1210  implementation of Xanalogical storage is Line 1188  implementation of Xanalogical storage is
1188  that Xanalogical storage necessiates strong discipline in version tracking,  that Xanalogical storage necessiates strong discipline in version tracking,
1189  which current systems lack.)  which current systems lack.)
1190    
1191    [worth to mention ? -Hermanni]
1192  .. An idea for future work in this area is investigating potential  .. An idea for future work in this area is investigating potential
1193     combinations of Gzz/Storm and the Object-Oriented Web publishing     combinations of Gzz/Storm and the Object-Oriented Web publishing
1194     environment Zope [ref zope.org/com, book, article?]. For example, Storm     environment Zope [ref zope.org/com, book, article?]. For example, Storm
# Line 1222  which current systems lack.) Line 1201  which current systems lack.)
1201     for the (even substantial) changes that 'xanalogicalising' it would mean     for the (even substantial) changes that 'xanalogicalising' it would mean
1202     in practise. For Gzz, Zope might provide a window to the Web.     in practise. For Gzz, Zope might provide a window to the Web.
1203    
1204    [worth to mention ? -Hermanni]
1205  .. interestingly zope by default stores diffs in the zodb (similarly:cvs&storm?)  .. interestingly zope by default stores diffs in the zodb (similarly:cvs&storm?)
1206     Benja also noted about pointing to external data? (couldn't find the post     Benja also noted about pointing to external data? (couldn't find the post
1207     from the archives)     from the archives)
1208    
1209    [worth to mention ? -Hermanni]
1210    design&impelement p2p functionality, where Symphony and Kademlia potential alternativies
1211    for DHT overlay
1212      
1213    [worth to mention, fetching data etc. ? -Hermanni]
1214    1) Open issue: Tree hashing, also possibly needed for (OceanStore-like?)
1215    distribution of shares
1216    
1217    2) Open issue/Future directions: implement multisource downloading
1218    
1219    [not worth to mention ? -Hermanni]
1220    .. [how does video work here, i.e. are they huge blocks or collections of many
1221       small, frames? or a sequence between two keyframes?]
1222    
1223       Benja says: Probably large, but the number of links to them
1224       still won't be that big, I guess. Not sure how to discuss this
1225       in the text; feel free to propose something :-)
1226    
1227       Toni: will try.. wondering also about who to consult :o
1228    
1229    [not worth to mention ? -Hermanni]
1230    Future directions: Implement home node model or directory model ?
1231    
1232    [not worth to mention ? -Hermanni]
1233    Open issue: Firewall Transparency/NATs ?
1234    
1235    [not worth to mention ? -Hermanni]
1236    Open issue: notes in the text about block sizes with video
1237    
1238    [not worth to mention, see above ? -Hermanni]
1239    Open issue: other related systems (within gzz?) for e.g. more synchronous
1240    collabaration (irc?)?
1241    
1242    [not worth to mention, see above OpenHyp paragraph ? -Hermanni]
1243  .. Investigating the degrees of interoperability with Open Hypermedia  .. Investigating the degrees of interoperability with Open Hypermedia
1244     (/Structural Computing?) and (more primitive?) other (Web) XXX is a possible     (/Structural Computing?) and (more primitive?) other (Web) XXX is a possible
1245     direction for future work, and will be preliminarly discussed here too.     direction for future work, and will be preliminarly discussed here too.
1246     [benja says: Really? Do we/can we discuss that really? antont: 'll try.]     [benja says: Really? Do we/can we discuss that really? antont: 'll try.]
1247     (checked OHProtocol, no fruit there yet)     (checked OHProtocol, no fruit there yet)
1248    
1249  When Xanalogical storage is not applied, using Storm as a  [not worth to mention, first p2p proto then these ;) ? -Hermanni]
 replacement/equivalent of a conventional file and versioning system is  
 trivial?  
   
1250  .. p2p -> cf half-life of peers (Mojo Nation): Is it desirable that 'weak' peers  .. p2p -> cf half-life of peers (Mojo Nation): Is it desirable that 'weak' peers
1251     participate in a DHT? -- In Circle, peers must have been online     participate in a DHT? -- In Circle, peers must have been online
1252     for at least an hour... In which ways, then, can 'weak' peers contribute     for at least an hour... In which ways, then, can 'weak' peers contribute
# Line 1244  trivial? Line 1255  trivial?
1255     potentially boost download speeds to the full available bandwidth).     potentially boost download speeds to the full available bandwidth).
1256     This is a performance/reliability issue rather than something     This is a performance/reliability issue rather than something
1257     changing the fundamental qualities of the network, but still important.     changing the fundamental qualities of the network, but still important.
1258      
1259    [not worth to mention ? -Hermanni]  
1260     [Symphony supports heterogeneity of peers -Hermanni]     [Symphony supports heterogeneity of peers -Hermanni]
1261    
1262    [not worth to mention ? -Hermanni]
1263     The important point about p2p publishing is that no account and setup     The important point about p2p publishing is that no account and setup
1264     is necessary to start publishing.     is necessary to start publishing.
1265    
1266    [not worth to mention ? -Hermanni]
1267     One possibility: Use IBP for limited-time publishing, referring to     One possibility: Use IBP for limited-time publishing, referring to
1268     the location through the DHT? This might be related to p2p publishing.     the location through the DHT? This might be related to p2p publishing.  
1269    
1270        
1271    
1272  8. Conclusions  8. Conclusions

Legend:
Removed from v.1.137  
changed lines
  Added in v.1.138

savannah-hackers-public@gnu.org
ViewVC Help
Powered by ViewVC 1.1.26