There are two assumptions that do not generally hold. 1) Both sides of links are always available at the same time (not true in case of NFS that is often symlinked). Just consider the case of notebook taken home and file system change in mean time. 2) There is a permission to change file system on the destination of the link (not true in the case of readonly remote file systems and DVDs). 3) Also, why the server file system should absorb additional cost for the each client? Is not it a hole to DoS it?
Best Regards, Constantine Plotnikov On Tue, Oct 7, 2014 at 8:41 PM, Casey Ransberger <casey.obrie...@gmail.com> wrote: > Context below, sorry about the top-post (stupid "smartphone.") > > I think I remember that in Xanadu, links are two-way streets. When you > "move" the link, I can only assume that both of those pointing devices > would need to be updated. > > I'm not sure how it works though. Is there a central authority involved, > can it be distributed, etc? It's hard to visualize a two-way link because I > have spent my entire life living in flatland. I even mix up which plane is > blue and which is pink sometimes:) > > The gist I got was that the two-way link concept was a powerful idea which > could be applied to more problems than just "pages" (the mere use of the > term is liable to give Ted a headache. Flat paper metaphors and such.) I > wouldn't be shocked if a good implementation couldn't be done using a > "vigilant" doubly-linked list (i.e. an object which cares about provenance > and has a means of vetting it, like perhaps a touch of public key > encryption.) Think of all the talk on this list about publish/subscribe as > an object model, pattern directed invocation and such, and then try to > imagine all of the ways a two-way link or "shortcut" might outclass the > usual (and fragile-as-glass) one-way link. > > BCC Ted Nelson on the off chance that he might like to help us visualize > the two-way link idea. (Ted, let me know if I shouldn't forward messages > like this to you. Seems like giving some researchers a view into some of > your ideas should help you on your way to realizing them. Then again, the > road to hell is paved with... irritating people forwarding messages with > good intentions.) > > Cheers, > > --Casey Ransberger > > > On Oct 5, 2014, at 5:52 AM, John Carlson <yottz...@gmail.com> wrote: > > > > To put the problem in entirely file system terminology, What happens to > a folder with shortcuts into it when you move the folder? How does one > automatically repoint the shortcuts? Has this problem been solved in > computer science? On linux, the shortcuts would be symbolic links. > > > > I had a dream about smallstar when I was thinking about this. The > author was essentially asking me how to fix it. He was showing me a > hierarchy, then he moved part of the hierarchy into a subfolder and asked > me how to automate it--especially the links to the original hierarchy. > > > > In language terms, this would be equivalent of refactoring a class which > gets dropped down into an inner class. This might be solved. I'm not sure. > > > > This would be a great problem to solve on the web as well...does Xanadu > do this? > > > > I think the solution is to maintain non-persistent nodes which are > computed at access time, but I'm not entirely clear. > > > > I have no idea why I am posting this to cap-talk. There may be some > capability issues that I haven't thought of yet. Or perhaps the capability > folks have already solved this. > > > > For your consideration, > > > > John Carlson > > _______________________________________________ > > fonc mailing list > > fonc@vpri.org > > http://vpri.org/mailman/listinfo/fonc > _______________________________________________ > fonc mailing list > fonc@vpri.org > http://vpri.org/mailman/listinfo/fonc >
_______________________________________________ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
