Thanks for the comments Greg! Could you expand upon what you mean by "predictable semantics"? I'm not sure what that entirely entails.
-Mark Berger PS: Here are some more comments I left on the ticket. ------------------- Comment (by markberger): * I agree that the feature should be at the protocol level. That was my original idea but I forgot to explicitly state that. * When I was talking about sharing, I had the idea of sharing via a publicly accessible gateway, similarly to how the tiddly wiki works. If a user is running their own client, shortcuts should be able to be used with the WUI, but I agree that it is not the way to share files. * You're right in that there are serious issues with the flat namespace. If accounting were implemented a user could have their own namespace for their respective shortcuts. On Tue, Jul 2, 2013 at 9:54 AM, Greg Troxel <g...@ir.bbn.com> wrote: > Mark, > > I put some thoughts in the ticket. (Perhaps tahoe-dev should get all > ticket updates? It seems better to have the conversation in the ticket, > so it's organized, but it risks leaving out people.) > > From: "tahoe-lafs" <t...@tahoe-lafs.org> > Subject: Re: [tahoe-lafs-trac-stream] [tahoe-lafs] #2010: Implement > shortcuts to caps > Cc: tahoe-lafs-trac-str...@tahoe-lafs.org > Date: Tue, 02 Jul 2013 13:52:27 -0000 (1 minute, 4 seconds ago) > Reply-To: tahoe-dev@tahoe-lafs.org > > #2010: Implement shortcuts to caps > > -----------------------------+-------------------------------------------- > Reporter: markberger | Owner: > Type: enhancement | Status: new > Priority: normal | Milestone: undecided > Component: code | Version: 1.10.0 > Resolution: | Keywords: usability, newurls, > introducer > Launchpad Bug: | > > -----------------------------+-------------------------------------------- > > Comment (by gdt): > > This is a major architectural change, to add a new namespace. Before it > happens, I think it needs a a complete written architectural design and > protocol explanation. A few concerns: > > * Absent a really good reason, the feature should be at the > protocol/WAPI > level, not at the WUI level. I think you meant that, but I'm not sure. > * This is basically an extension to the aliases file, with a grid-wide > shared namespace. So perhaps having an aliases.public that is published > would make sense. > * One needs to have unpublish if there is publish, probably. > * Synchronization of aliases should have predictable semantics. > Re-fetch > on miss does not satisfy this. > * I think sharing by pointing at a foreign WUI is bad practice; that's > a > hack for a web server with a tahoe backend filesystem. Sharing by a > cap > that allows the reader to find an introducer and speak the protocol is > another matter. > * It seems clear to me from reading your examples that there are > serious > issues with a flat namespace in a grid with multiple people. > * The mechanism could be abused to store (small amounts) of data > without > write authorization, but perhaps that's not incrementally a bug. Once > there is write authorization in place, this will be a bug. > > -- > Ticket URL: < > https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2010#comment:1> > tahoe-lafs <https://tahoe-lafs.org> > secure decentralized storage > _______________________________________________ > tahoe-lafs-trac-stream mailing list > tahoe-lafs-trac-str...@tahoe-lafs.org > https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-lafs-trac-stream >
_______________________________________________ tahoe-dev mailing list tahoe-dev@tahoe-lafs.org https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev