On Mon, Feb 06, 2006 at 11:15:06PM +0100, Marcus Brinkmann wrote: > At Fri, 3 Feb 2006 10:55:21 +0100, > Bas Wijnen <[EMAIL PROTECTED]> wrote: > > > > On Thu, Feb 02, 2006 at 01:56:50PM -0500, Marcus Brinkmann wrote: > (But then, in a POLA system you would probably move the file->open > dialog into the shell, reducing the number of affected applications to > one...).
Yes, but we will need to supply a POSIX environment as well, which doesn't work that way (at least for a probably quite long transition period). Denying them the multi-facet view is a severe limitation for them, which should be avoided if at all possible. I don't think requiring a change to all of them to use the shell as a proxy for opening files is doable. It would be possible to move that into libc, but that would result in a very hacked-together interface (think of any program opening a lot of files, such as find). > > > Using the poly-type approach would remove all ambiguities: Applications > > > would either see a file or a directory, but not both. Applications who > > > _know_ about hybrid types can use the new functions to switch facets > > > explicitely. If a user wants to use an application with a hybrid type, > > > he will have to make his intent explicit by providing the node with the > > > right facet type to the application. > > > > This sounds good. I think I would like to have the creation of the nodes > > with other facets (so the creation of "foo" when "foo.tar.gz" exists) > > explicit. That is, the user has to do it. Otherwise there will be too > > many name space collisions. For example, it is usual that a foo.tar.gz > > unpacks a directory called foo and files inside it. If that directory and > > those files already exist, strange things will happen when a script > > unpacks it, possibly removing the directory first. > > Yes, choosing the names is a problem. However, I am not sure you can > always leave this to the user. There is a strong motivation to enter > tar.gz files automatically by double-clicking on them. Asking for a > directory name would remove the transparency. I would consider a setting "open under name 's/(.*)\.tar\.gz/\1/'" in some config file of the graphical shell. That's enough "leaving the decision to the user" for me: the user chooses the name, and the user decides to bind it (by double clicking on the file). An other question is if it should unbind when leaving the directory. I think it probably should. However any other process which entered the binding should have added the "reference count", and it should only be unbound when as many processes have unbound it as have bound it. > I have not thought about this problem, but it seems to me that at least > within the interactive graphical shell there can be a strong convention. In > fact, the shell does not even need to create the different facets in the > same directory as the "facetted" file---it can use a private scratch area. It could do this, but I think it would be useful to have it at least reachable for other (POSIX) applications. It's useful to right-click on a file and say "open with". Then the program which opens the file must be able to reach it by path (because that's the only way most POSIX applications understand). > This is one area of the multi-facetted solution that would need to be > worked out. If different filenames are used for different facets (which is required for POSIX applications), then in principle this could be done with translators. The only difference is that (semi-)automatic binding of the appropriate translators to each file. Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://129.125.47.90/e-mail.html
signature.asc
Description: Digital signature
_______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
