Re: [fonc] Unsolved problem in computer science? Fixing shortcuts.
One might argue that this applies as nicely to files as to network addresses: A name indicates what we seek. An address indicates where it is. A route indicates how to get there. -- Jon Postel, in RFC791 (Internet Protocol) Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Unsolved problem in computer science? Fixing shortcuts.
The original question seems to be how to maintain links when the file is moved or renamed. Perhaps the file could have a unique ID in the file system, and the link would try the given pathname, but if it's not there, try the unique ID. Would that work? ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Unsolved problem in computer science? Fixing shortcuts.
Daniel W Gelder daniel.w.gel...@gmail.com writes: The original question seems to be how to maintain links when the file is moved or renamed. Perhaps the file could have a unique ID in the file system, and the link would try the given pathname, but if it's not there, try the unique ID. Would that work? That's about what is done by MacOS and MacOSX (at least on HFS, I don't know if they do the same on UFS). This let aliases to keep working when you move the target files. So aliases, which in a way are more like symbol links (if you delete the target file and recreate it in the same path, then the alias will refer the new file), actually behave more like symbolic links in that you can move the target file, and the alias will still refer it. Now the question, is what happens if you move away the original target, and recreat a new one in the old path? As a MacOS and then MacOSX user, I DO NOT KNOW! I would have to try it. The point is that the semantics of symbolic links and of hard links are clear and easy to understand, and manipulate. The semantics of MacOS and MacOSX aliases are not. And I don't know anything about links in MS-Windows (I'd expect they'd work as broken Mac aliases). There's some level of DWIM in that. The question should be whether we want a system that DWIM, or whether we want a system that implement simple and composable operations that can easily be understood and used? -- __Pascal Bourguignon__ http://www.informatimago.com/ “The factory of the future will have only two employees, a man and a dog. The man will be there to feed the dog. The dog will be there to keep the man from touching the equipment.” -- Carl Bass CEO Autodesk ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Unsolved problem in computer science? Fixing shortcuts.
We may want a program which unfortunately has a path to a shortcut to still work if the files they point to are moved. On Oct 9, 2014 7:56 PM, Pascal J. Bourguignon p...@informatimago.com wrote: Daniel W Gelder daniel.w.gel...@gmail.com writes: The original question seems to be how to maintain links when the file is moved or renamed. Perhaps the file could have a unique ID in the file system, and the link would try the given pathname, but if it's not there, try the unique ID. Would that work? That's about what is done by MacOS and MacOSX (at least on HFS, I don't know if they do the same on UFS). This let aliases to keep working when you move the target files. So aliases, which in a way are more like symbol links (if you delete the target file and recreate it in the same path, then the alias will refer the new file), actually behave more like symbolic links in that you can move the target file, and the alias will still refer it. Now the question, is what happens if you move away the original target, and recreat a new one in the old path? As a MacOS and then MacOSX user, I DO NOT KNOW! I would have to try it. The point is that the semantics of symbolic links and of hard links are clear and easy to understand, and manipulate. The semantics of MacOS and MacOSX aliases are not. And I don't know anything about links in MS-Windows (I'd expect they'd work as broken Mac aliases). There's some level of DWIM in that. The question should be whether we want a system that DWIM, or whether we want a system that implement simple and composable operations that can easily be understood and used? -- __Pascal Bourguignon__ http://www.informatimago.com/ “The factory of the future will have only two employees, a man and a dog. The man will be there to feed the dog. The dog will be there to keep the man from touching the equipment.” -- Carl Bass CEO Autodesk ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Unsolved problem in computer science? Fixing shortcuts.
Josh McDonald j...@joshmcdonald.info writes: Why should links be in the filesystem, rather than an application / UI construct? For a lot of reasons. But the question is justified. - because it would be more modular and represent more code reuse, to factorize out the management of links in the file system module, rather than having it in each application. - because that would provide the user with a more consistent user experience (both look and feel), than when each application implements its own semantics and user interface to manage files (as we can see on the horrible iOS and Android systems). - because providing a generic tool to manipulate files let the users control their data, contrarily to putting the application (and therefore, unless it's a GPL application readable, understandable, modifiable and compilable by the user, is actually a proxy of the commercial or political interests that provide this application to the slave^W user. Notice the qualificatifs, the GPL is not enough: how many users can read, understand, modify and compile the source of the GPL application they use (take for example LibreOffice oremacs). The points here are that: 1- applications are not written in languages that are readable by the (non programmer) users. 2- applications are not written in a way that is understandable by their users. 3- and therefore, applications are not modifiable and compilable by users. Therefore, embedding important features such as file system management into applications is strongly restrictive of users' freedom, taking control over users' data. The GPL idea would be that users could contract programmers to help them with those point. How many times did users contract you to read GPL programs, or to modify them? (cf. the recent openssl and bash bugs). Until there is a lot of changes in the way applications are written, and in the way they are licensed and distributed, embedding file system management features in the applications (or in the frameworks used by the application, like Cocoa and iOS try to do), is very bad. Why should there be 1 filesystem, rather than 0, or thousands? Indeed. There can as many file systems as you wish, and a system should provide a way to manage as many file systems as you wish. The unix systems let you do that, with the mount(2)/umount(2) and chroot(2) primitives. Linux helps even more with bind move and shared mounts. But otherwise, this question refers to capability based systems which often provide explicitely set-up per-process directories to give access explicitely to authorised files. Indeed, this seems to be a good way to avoid a lot of security problems. The question is how to design a user interface letting us do that conveniently enough. (And again, there's the question of trusting the programs that perform those tasks anyways, can those programs be read and modified by the users (with the required capabilities)? Why must a filesystem be a DAG + links, rather than some other graph, or a soup with a lot of queries? See my previous answer. Again, you're right to ask the question. Trees are but a simple way to manage files where the human user keeps control of it. Granted, when managing libraries of millions of pictures or mp3 songs, other organization scheme, more automatic, and more multidimensional may be required. This becomes more a database than a (classic) file system. Should the system integrate database systems to manage files (like old mainframe systems), or should unix stay a uni-user simple system (unix) instead of becoming a multi-user complex system (multics)? Just joking anyways, I'm on the Lisp Machine side of things. My point here is that it is a difficult problem to solve satisfatorily: - you need to provide a generic file system module that is independent of applications to let the user keep ownership of their files despite using privative applications, - you now need to provide a database system that works for all kind of different applications with different requirements, - nowadays, you might also need to integrate remote files (cloud storage, etc), behind this database API. Why should a link simply be a file pretending to be in two directories at once, rather than a data-carrying relationship between two nodes in the graph? Well, in the current situation, links carry information: their name, and a few file system attributes are link-specific. An application can take advantage of it. An example, is scripts with care called with different symbolic link names and perform different actions accordingly. But granted, in a database view of the thing, you might want to add other attributes. I think these are much more interesting questions :) Yes. -- __Pascal Bourguignon__ http://www.informatimago.com/ “The factory of the future will have only two employees, a man and a
Re: [fonc] Unsolved problem in computer science? Fixing shortcuts.
i think the source of the problem usually is that references are not encoding the intention properly (certainly in the case of symlinks). let's consider references in the context of e.g. a computer programs: in prevalent programming languages/systems a call site is referencing a function by a string (by the function's name), which is resolved in one of the phases in the complex process of executing the program. this is a good example of lost intention. consider computer programs as what they really are, namely graphs, as opposed to flat text files: at the call site did the programmer reference that specific version of the function definition? if someone modifies the definition then should the call site call the old definition or the new one? if someone renames the definition then should the call site refer to the same definition or become a broken link? and a tangential to ponder about: for a compiler algorithm a program means exactly the same even if we throw away all the names after name resolution phase. mainstream computing systems in general have no clear abstraction for first class identity management, and due to that references are also murky. e.g. if i look up a movie on imdb.com, and when i drop it on my desktop, then i want my computing system to display the identity of that movie, or in short: the movie. not a file, not a specific video stream representing that movie, not a URL to imdb.com, not the name of the movie... but its identity, the movie itself. and the same applies when i drag and drop that icon again into a chat message. so, in short: express your intention with high precision in the references and in the data structures in general, and then the solution will be trivial (which doesn't mean that properly identifying your intentions is easy). -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “Merely having an open mind is nothing; the object of opening the mind, as of opening the mouth, is to shut it again on something solid.” — G.K. Chesterton ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Unsolved problem in computer science? Fixing shortcuts.
Interesting.. Last time a thought about this I figured that a solution could be to split identity from location. That is, the location of a file is currently part of its identity, so when you moved it, all links that refer to it break. If, however, all files where given a unique identifier (a GUID for example), and there where a master index mapping files (via ID) to their location, links would then just keep working unmodified however you moved the files. An equivalent problem (IIUC) is to copy an object graph. Here, the straightfoward solution is to index all objects into a sequence, represent all links as indices into that sequence, copy the sequence, then rebuild the links easily from the indices. Here you can see that identity (the index into the sequence) is split from location (the storage of the object). Most typical graph representations merge both by having links refer directly to the related objects (such as having a pointer to it), so the solution to the copy problem is to decompose that. For this reason, I often represent object graphs explicitely that way: all objects are stored in a sequence container and links are just indices. I do realise of course that maintaining a gigantic master index of all files is not applicable to the real world, but nonetheless I think the general form of the solution (split identity from location) is worth being considered. Best On Tue, Oct 7, 2014 at 9:22 AM, Attila Lendvai attila.lend...@gmail.com wrote: i think the source of the problem usually is that references are not encoding the intention properly (certainly in the case of symlinks). let's consider references in the context of e.g. a computer programs: in prevalent programming languages/systems a call site is referencing a function by a string (by the function's name), which is resolved in one of the phases in the complex process of executing the program. this is a good example of lost intention. consider computer programs as what they really are, namely graphs, as opposed to flat text files: at the call site did the programmer reference that specific version of the function definition? if someone modifies the definition then should the call site call the old definition or the new one? if someone renames the definition then should the call site refer to the same definition or become a broken link? and a tangential to ponder about: for a compiler algorithm a program means exactly the same even if we throw away all the names after name resolution phase. mainstream computing systems in general have no clear abstraction for first class identity management, and due to that references are also murky. e.g. if i look up a movie on imdb.com, and when i drop it on my desktop, then i want my computing system to display the identity of that movie, or in short: the movie. not a file, not a specific video stream representing that movie, not a URL to imdb.com, not the name of the movie... but its identity, the movie itself. and the same applies when i drag and drop that icon again into a chat message. so, in short: express your intention with high precision in the references and in the data structures in general, and then the solution will be trivial (which doesn't mean that properly identifying your intentions is easy). -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “Merely having an open mind is nothing; the object of opening the mind, as of opening the mouth, is to shut it again on something solid.” — G.K. Chesterton ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc -- Fernando Cacciola SciSoft Consulting, Founder http://www.scisoft-consulting.com ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Unsolved problem in computer science? Fixing shortcuts.
On Tue, Oct 7, 2014 at 11:29 AM, Fernando Cacciola fernando.cacci...@gmail.com wrote: I do realise of course that maintaining a gigantic master index of all files is not applicable to the real world, but nonetheless I think the general form of the solution (split identity from location) is worth being considered. OTOH, it just ocurred to me that this can be made to scale to the real world in the following way: A file could be formally classified a standalone or multiply-referenced. A standalone file would be one which doesn't have an entry in the master index. A multiply-referenced file would be listed in the master index, given a unique id and mapped to its current location. When you create a new link, the file is given a unique id, added to the master index and the link is associated to the target's id. The master index can even have a reference count allowing the file to transition to standalone state when the last link is removed. This way the master index size is kept bounded by the number of effective links in the file system. Best -- Fernando Cacciola SciSoft Consulting, Founder http://www.scisoft-consulting.com ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Unsolved problem in computer science? Fixing shortcuts.
The problem with fixing shortcuts in file-systems, and with links and with names and with files in filesystems in general, is that the intention of the link, and even of a filename is not clear. For a simple example, compare a jpeg of your cat to a configuration file, e.g. /etc/passwd. It is silly to keep multiple copies of the jpeg of your cat in multiple locations on your hard drive just because you use it as your desktop wallpaper, have it in a slideshow, have referenced it in a newsletter, etc. but if you move or rename the file you would prefer that all these references to it don't suddenly break. In this case you might say that your intention is to refer to -this- file, regardless of name or location. Even an updated picture is not the same picture. Links to this file are perhaps intended to be links to this specific image. On the other hand, your /etc/passwd file tracks the users of your computer. When you update the file to change your password you don't want the system to keep referring to the old file. When you copy the file elsewhere for backups you don't want the system to go looking in the new location instead of the old location. In this case the intention is to refer to -any- file that is found in -this- location. Links to this file are intended to be links to this location. An interesting approach is to separate the naming concern from the content concern. One project is doing exactly this: http://camlistore.org (Content-Addressable Multi-Layer Indexed Storage.) The contents of files are stored as blobs and are addressed by the hash of their contents. Those hashes are referred to by claims, which are similar to the filenames and directories and links of a conventional file system. A natural consequence of this system is that de-duplication is built in and replication is simple. It has not been designed to be suitable for a high-performance file system though. Chuck On Oct 7, 2014, at 7:42 AM, Fernando Cacciola fernando.cacci...@gmail.com wrote: On Tue, Oct 7, 2014 at 11:29 AM, Fernando Cacciola fernando.cacci...@gmail.com wrote: I do realise of course that maintaining a gigantic master index of all files is not applicable to the real world, but nonetheless I think the general form of the solution (split identity from location) is worth being considered. OTOH, it just ocurred to me that this can be made to scale to the real world in the following way: A file could be formally classified a standalone or multiply-referenced. A standalone file would be one which doesn't have an entry in the master index. A multiply-referenced file would be listed in the master index, given a unique id and mapped to its current location. When you create a new link, the file is given a unique id, added to the master index and the link is associated to the target's id. The master index can even have a reference count allowing the file to transition to standalone state when the last link is removed. This way the master index size is kept bounded by the number of effective links in the file system. Best -- Fernando Cacciola SciSoft Consulting, Founder http://www.scisoft-consulting.com ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Unsolved problem in computer science? Fixing shortcuts.
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
Re: [fonc] Unsolved problem in computer science? Fixing shortcuts.
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
Re: [fonc] Unsolved problem in computer science? Fixing shortcuts.
If you have symbolic reference, you have to be ready that destination is gone, moved, or goes offline. Otherwise use hardlinks. You also could create a defensive layer of symlinks just for indirection. Nothing could be done in the distributed case anyway, because destination could change while source of the link is offline. Just to gerneralize things further, consider the case when renamed file is referenced from other file. Should content of the referrer file to change as well? After all symlink or shortcut is just a file that contains name of other file as content, but treated specially by operating system. BTW the problem is not a new one. The partinal solution for PL is called refactoring. Best Regards, Constantine Plontikov On Sun, Oct 5, 2014 at 4:52 PM, 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
Re: [fonc] Unsolved problem in computer science? Fixing shortcuts.
Isn't the obvious answer to use indirect addressing via a directory? John Carlson 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 -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Unsolved problem in computer science? Fixing shortcuts.
Not obvious to me. Are you saying a folder of shortcuts? A shortcut to a folder? A shortcut to a shortcut to a folder? Instead of using indirect addressing, can you put it in terms of folders and shortcuts, or do we need a third type of object? And how does this apply to a general graph problem? Are you speaking of URNs? A directory of hard links? That seems to make the most sense to me, and would bring in the third type of object. Can you really make a hard link to a directory, and expect it to work? I'm not thinking of something with two levels, I am thinking of a multilevel problem, where the shortcuts go really deep, like from a desktop to somewhere into program files. If I rename a program files folder, what happens to my shortcuts? If you like I can put this into Linux/BSD terms which I am more comfortable with. I am trying to address it to a larger audience than that though. On Sun, Oct 5, 2014 at 8:49 AM, Miles Fidelman mfidel...@meetinghouse.net wrote: Isn't the obvious answer to use indirect addressing via a directory? John Carlson 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 -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Unsolved problem in computer science? Fixing shortcuts.
One thing that comes to mind are copying garbage collectors which need to keep track of references while moving objects around. Probably looking into how that is solved will provide some insight. On Sun, Oct 5, 2014 at 12:35 PM, John Carlson yottz...@gmail.com wrote: Not obvious to me. Are you saying a folder of shortcuts? A shortcut to a folder? A shortcut to a shortcut to a folder? Instead of using indirect addressing, can you put it in terms of folders and shortcuts, or do we need a third type of object? And how does this apply to a general graph problem? Are you speaking of URNs? A directory of hard links? That seems to make the most sense to me, and would bring in the third type of object. Can you really make a hard link to a directory, and expect it to work? I'm not thinking of something with two levels, I am thinking of a multilevel problem, where the shortcuts go really deep, like from a desktop to somewhere into program files. If I rename a program files folder, what happens to my shortcuts? If you like I can put this into Linux/BSD terms which I am more comfortable with. I am trying to address it to a larger audience than that though. On Sun, Oct 5, 2014 at 8:49 AM, Miles Fidelman mfidel...@meetinghouse.net wrote: Isn't the obvious answer to use indirect addressing via a directory? John Carlson 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 -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra ___ 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
Re: [fonc] Unsolved problem in computer science? Fixing shortcuts.
That sounds like a good idea. I like it because it operates on more than one dataset. However, we'll need to track paths as well as just references. This is already done for circular references in garbage collectors, so it might be just the ticket. What I am wondering is if this sort of thing could be handled by a possibly modified Journaling file system. If the journal maintains the important stuff, couldn't it be looked at for any folder moves which affect shortcuts? On Oct 5, 2014 2:21 PM, Tristan Slominski tristan.slomin...@gmail.com wrote: One thing that comes to mind are copying garbage collectors which need to keep track of references while moving objects around. Probably looking into how that is solved will provide some insight. On Sun, Oct 5, 2014 at 12:35 PM, John Carlson yottz...@gmail.com wrote: Not obvious to me. Are you saying a folder of shortcuts? A shortcut to a folder? A shortcut to a shortcut to a folder? Instead of using indirect addressing, can you put it in terms of folders and shortcuts, or do we need a third type of object? And how does this apply to a general graph problem? Are you speaking of URNs? A directory of hard links? That seems to make the most sense to me, and would bring in the third type of object. Can you really make a hard link to a directory, and expect it to work? I'm not thinking of something with two levels, I am thinking of a multilevel problem, where the shortcuts go really deep, like from a desktop to somewhere into program files. If I rename a program files folder, what happens to my shortcuts? If you like I can put this into Linux/BSD terms which I am more comfortable with. I am trying to address it to a larger audience than that though. On Sun, Oct 5, 2014 at 8:49 AM, Miles Fidelman mfidel...@meetinghouse.net wrote: Isn't the obvious answer to use indirect addressing via a directory? John Carlson 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 -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra ___ 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 ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
