@vidarh

Quote:

The biggest problem is crossing volume boundaries.

I've been just struck by this idea: what if each volume where applications are had a :Applocations directory and the implicit command path included all the :Applocations directories on all currently mounted volumes? This way, there would be no need for BLs across devices and would solve all the related problems discussed above.

_________________
RETREAM - retro dreams for Amiga, Commodore 64 and PC

@saimo

Quote:

This would require the APPDIR: server to request notification for each and every executable managed: is this feasible? How much would it cost?

It would require pretty much the same as what the current AppDir apparently does. The current solution was reported to trigger for anything that is LoadSeg()'d. To handle renames etc. you'd need a bit more but not much. The cost is a single message sent to a message port for those calls to dos.library, and for the AppDir task to eventually process them. Cost wise it shouldn't be much of an addition to what AppDir already does unless you do mass renaming of files on a regular basis :)

Quote:

Well, for the applocations system all that's needed is 1:1 links, but I'm not absolutely against a 1:N implementation - if its complexity can be handled reasonably, it's a problem of who has to write the code

The complexity of the "weak hardlink" solution (i.e. equivalent to OS X "aliases") I mentioned is low for within the same volume (which would work with your revised idea of a "applocations" per volume), but it obviously would require filesystem changes which is never non-trivial. Proper bidirectional softlinks could potentially be quite a bit more complex if you want 1:n.

A "higher level" solution similar to AppDir has the benefit that it could potentially be done with some strategic use of SetFunction()/SetMethod(), which means "someone" could prototype it without needing any support/changes from Hyperion.

_________________
Wiki for new/returning Amiga users - Projects: ACE basic compiler / FrexxEd / Git

@vidarh

Quote:

The complexity of the "weak hardlink" solution (i.e. equivalent to OS X "aliases") I mentioned is low for within the same volume (which would work with your revised idea of a "applocations" per volume), but it obviously would require filesystem changes which is never non-trivial. Proper bidirectional softlinks could potentially be quite a bit more complex if you want 1:n.

I'd be more than happy even with just 1:1 weak hardlinks/softlinks, as those would be sufficient for the applocations system (which is what I care about the most here)
If the filesystem maintainer(s) also feel that adding "stronger" links is possible, even better, as the whole system would be enriched with a powerful feature
Yes, making changes/additions to filesystems is a very, very delicate issue, but it doesn't have to happen all of a sudden and it might be (well, IMHO it is) worth it

Quote:

A "higher level" solution similar to AppDir has the benefit that it could potentially be done with some strategic use of SetFunction()/SetMethod(), which means "someone" could prototype it without needing any support/changes from Hyperion.

I reckon it isn't wise to let such a key feature be handled by third, unofficial parties.

Last edited by saimo on 20-Jan-2010 at 11:20 PM.
Last edited by saimo on 20-Jan-2010 at 06:40 PM.

_________________
RETREAM - retro dreams for Amiga, Commodore 64 and PC

@saimo

I personally think that APPDIR: is more robust than your idea. It automatically adapts to changes in the system, albeit delayed until a particular app is run directly, and it doesn't rely on any directory structure, soft-links, etc. In short, APPDIR: requires zero changes to the rest of the system, it doesn't affect performance, and it doesn't get in the way of those who don't use it. Having SYS:AppLocations does require messing with the file-systems, and requires more effort to maintain.

The problem of APPDIR: not knowing about applications until they are run once could be solved by providing installers with the ability to register apps. Other than that, I think that it works fine as-is.

Hans

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more. Home of the RadeonHD driver for Amiga OS 4.x project.
https://keasigmadelta.com/ - More of my work.

@Hans

Quote:

I personally think that APPDIR: is more robust than your idea.

I disagree for the reasons explained in this thread, in the related threads and below.

Quote:

It automatically adapts to changes in the system,

Absolutely not: in its current form, the minute you move/rename/delete an application, you get an invalid entry which doesn't get fixed automatically, but at most later and probably with the user intervention (as you say just below).

Quote:

albeit delayed until a particular app is run directly,

And this is an annoying shortcoming, to say the least.

Quote:

and it doesn't rely on any directory structure, soft-links, etc.

It relies on an additional device (and all the related resources), on the ENVARC: + ENV: mechanism and also on a directory structure, since ENVARC: is filesystem-based.

Quote:

In short, APPDIR: requires zero changes to the rest of the system,

It requires changes itself (because, as it is now, it isn't good enough) and, anyway, it is itself an addition to the system that adds more complexity (there is a new device with its own tasks, its need of notifications, its caching/maintainance policies and so on).

Quote:

it doesn't affect performance,

I'd say it does more than the applocations would, as it involves additional tasks/processes, IPC and periodical mantainance (at least in its current form), whereas the applocations system only requires an additional feature in the filesystem that doesn't require any asynchronous operation.

Quote:

and it doesn't get in the way of those who don't use it.

False: I don't use it, but the moment some software not written by me starts using APPDIR:, it gets in my way.
On the other hand, the applocations system is totally transparent and even more comfortable (not even something as short as "APPDIR:" needs to be specified anymore: the bare commands names are all that's needed anytime anywhere).

Quote:

Having SYS:AppLocations does require messing with the file-systems, and requires more effort to maintain.

The applocations system only requires an additional feature in the filesystem (BLs), which might as well be useful for other purposes. Accessing the entries in the :Applocations directories is done by means of the command path we already have and creating/updating them requires no more effort than maintaining ENVARC:Appdir.
Finally, maintaining the applocations system as a whole is much easier because the system is intrinsically simple. The hard part is only adding BLs to the filesystems, but that's something that, once in place, hardly requires frequent updates, extensions, etc. (moreover, since we already have links, maybe adding BLs could not be so terribly difficult).

Quote:

The problem of APPDIR: not knowing about applications until they are run once could be solved by providing installers with the ability to register apps. Other than that, I think that it works fine as-is.

Sorry, but it seems you're missing the other shortcomings of APPDIR:, which have been exposed quite well in the other threads.

Last edited by saimo on 20-Jan-2010 at 11:17 PM.
Last edited by saimo on 20-Jan-2010 at 11:16 PM.
Last edited by saimo on 20-Jan-2010 at 11:15 PM.

_________________
RETREAM - retro dreams for Amiga, Commodore 64 and PC

@saimo

Oh dear, I'll go through this step by step.

Quote:

saimo wrote: @Hans Quote: It automatically adapts to changes in the system, Absolutely not: in its current form, the minute you move/rename/delete an application, you get an invalid entry which doesn't get fixed automatically, but at most later and probably with the user intervention (as you say just below).

I just tested it, and it gets fixed the moment that you run the app directly. If you hadn't cut this sentence up into multiple fragments, then you would have seen that this is what I was talking about. Your suggestion would be unable to do this (unless you make major changes to the filesystems, installers, etc.). Moreover, cutting sentences into fragments and then dissecting the fragments is bad practise; you lost the context of things by doing so.

Quote:

Quote: albeit delayed until a particular app is run directly, And this is an annoying shortcoming, to say the least.

Yes, but this could actually be addressed by APPDIR, but not by a directory with soft/hard links (forget BLs for now).

Quote:

Quote: and it doesn't rely on any directory structure, soft-links, etc. It relies on an additional device (and all the related resources), on the ENVARC: + ENV: mechanism and also on a directory structure, since ENVARC: is filesystem-based.

Using an additional device is a much better method of handling this, than modifying the target partition directly. My point is that this is invisible to the user (except for people who like snooping aroung ENVARC:). It doesn't require applications/installers to register anything, so it works with all existing software. Of course the data has to be stored somewhere, and ENVARC: is the correct place for this; adding directories and links to the hard-drive right in the root, or even in sub-directories, is the wrong way to go about this. I guarantee you that there would be people who would complain about these AppLocations directories that pop up without their consent. Contrast this with the fact that you wouldn't even have known that APPDIR: existed, and cached stuff unless someone had told you.

Quote:

Quote: In short, APPDIR: requires zero changes to the rest of the system, It requires changes itself (because, as it is now, it isn't good enough) and, anyway, it is itself an addition to the system that adds more complexity (there is a new device with its own tasks, its need of notifications, its caching/maintainance policies and so on).

You misunderstood (or you're ignoring) what I wrote. APPDIR: does NOT interfere with the operation of the rest of the system, or the way that the user set up his/her hard-drive. It requires no changes to applications or installers to support it; it's transparent to the rest of the system.

Quote:

Quote: it doesn't affect performance, I'd say it does more than the applocations would, as it involves additional tasks/processes, IPC and periodical mantainance (at least in its current form), whereas the applocations system only requires an additional feature in the filesystem that doesn't require any asynchronous operation.

Have you noticed any performance hit? No, you haven't. It runs at priority -99, so it only works when the system has free CPU cycles to spare, i.e., when you're not using it. You're also making too many assumptions about how APPDIR is implemented.

Quote:

Quote: and it doesn't get in the way of those who don't use it. False: I don't use it, but the moment some software not written by me starts using APPDIR:, it gets in my way. On the other hand, the applocations system is totally transparent and even more comfortable (not even something as short as "APPDIR:" needs to be specified anymore: the command name is all that's needed anytime anywhere).

Come on, this is way too convoluted to be taken seriously. If some software uses it and it does its task, then you won't even notice that has happened. That's not "getting in your way;" it hasn't imposed anything on you; it's done its job.

Quote:

Quote: Having SYS:AppLocations does require messing with the file-systems, and requires more effort to maintain. The applocations system only requires an additional feature in the filesystem (BLs), which might as well be useful for other purposes. Accessing the entries in the :Applocations directories is done by means of the command path we already have and creating/updating them requires no more effort than mantaining ENVARC:Appdir. Finally, maintaining the applocations system as a whole is much easier because the system is intrinsically simple. The hard part is only adding BLs to the filesystems, but that's something that, once in place, hardly requires frequent updates, extensions, etc. (moreover, since we already have links, maybe adding BLs could not be so terribly difficult).

And what if a file is transferred to a partition that doesn't support bidirectional links? Oops, everything falls over. APPDIR: could be made to handle this efficiently without having to make fundamental changes to the way that file-systems work (BLs can't just be tacked on).

Added to that, I still think that having an AppLocations directory appear in root is more intrusive then a cache hidden in ENVARC:

Quote:

Quote: The problem of APPDIR: not knowing about applications until they are run once could be solved by providing installers with the ability to register apps. Other than that, I think that it works fine as-is. Sorry, but it seems you're missing the other shortcomings of APPDIR:, which have been exposed quite well in the other threads.

I'm going to be blunt here, the "shortcomings" that I have read about are a joke.

Hans

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more. Home of the RadeonHD driver for Amiga OS 4.x project.
https://keasigmadelta.com/ - More of my work.

@saimo

This is my final post on the matter. You'll just have to accept that I don't like your suggestion, and I disagree with your opinion about the APPDIR:. I do not want to see yet another "solution" to the same problem.

Hans

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more. Home of the RadeonHD driver for Amiga OS 4.x project.
https://keasigmadelta.com/ - More of my work.

@Hans

To me most all issues Saimo is trying to resolve could be cleared up quite neatly with the file notification system talking to the appdir: device in some way. Any moved or deleted applications would be automagically taken care of.

New applications should already be registered with the "application library" - isn't that the standard when installing new apps? If so an additional poke to appdir: should be built in to that, shouldn't it?


@Saimo

The link idea was good but it has too many holes. Clinging to the idea by suggesting bi-directional links is just making it worse.

I have made suggestions to deal with all the issues raised:
- multiple versions
- multiple alternates to same command
- apps being moved/deleted

You have not. I'm done.

@Hans

Quote:

I just tested it, and it gets fixed the moment that you run the app directly.

I never said this doesn't work.

Quote:

If you hadn't cut this sentence up into multiple fragments, then you would have seen that this is what I was talking about. Your suggestion would be unable to do this (unless you make major changes to the filesystems, installers, etc.). Moreover, cutting sentences into fragments and then dissecting the fragments is bad practise; you lost the context of things by doing so.

I'll answer to the bolded parts just to show you that I read what you wrote and that I didn't do anything to ignore it or, even worse, cheat - nothing personal
While we're at it, please note that in the parts below I had to cut some context for the simple reason that third-level quotes don't work.

I did see and correctly acknowledge what you underline - please note my "(as you say just below)" in the following, whole, context taken from the post you refer to:

Quote:

Quote: It automatically adapts to changes in the system, Absolutely not: in its current form, the minute you move/rename/delete an application, you get an invalid entry which doesn't get fixed automatically, but at most later and probably with the user intervention (as you say just below). Quote: albeit delayed until a particular app is run directly, And this is an annoying shortcoming, to say the least.

Can you see now? I did read and take into account all you said, and answered accordingly.

Quote:

Quote: Absolutely not: in its current form, the minute you move/rename/delete an application, you get an invalid entry which doesn't get fixed automatically, but at most later and probably with the user intervention (as you say just below). I just tested it, and it gets fixed the moment that you run the app directly. If you hadn't cut this sentence up into multiple fragments, then you would have seen that this is what I was talking about. Your suggestion would be unable to do this (unless you make major changes to the filesystems, installers, etc.).

In the applocation system the entry would not break in first place.
As regards the addition of new entries, the solutions for both systems would be identical (f.ex., the create-upon-execution thing).
This sentence clearly shows you did not (fully) understand my idea. I'll make a recap in another post that hopefully will describe the system to everybody in a better way than in the opening post.

Quote:

Quote: And this is an annoying shortcoming, to say the least. Yes, but this could actually be addressed by APPDIR, but not by a directory with soft/hard links (forget BLs for now).

Could, but it isn't. And the notification-based mechanism that would implement that would be less robust and more complex than a synchronous fix-link operation by the filesystem (why should I forget about BLs?).

Quote:

Quote: It relies on an additional device (and all the related resources), on the ENVARC: + ENV: mechanism and also on a directory structure, since ENVARC: is filesystem-based. Using an additional device is a much better method of handling this, than modifying the target partition directly. My point is that this is invisible to the user (except for people who like snooping aroung ENVARC:).

I'd personally be all for hiding the directory. And we already have a way to do it: it's enough not to associate a real icon to it to hide it in "show only icons" WB mode (and it'd be crazy to associate an icon anyway). OK, it would show in other view modes or tools, but would it be such a big problem? - after all, in those cases, it's precisely the user who is requesting a detailed view.
(More about this below.)

Quote:

It doesn't require applications/installers to register anything, so it works with all existing software.

Same goes for the applocations system. Where did you get this idea from?
Again, the APPDIR: and applocations systems require the same solutions, in this regard.

Quote:

Of course the data has to be stored somewhere, and ENVARC: is the correct place for this; adding directories and links to the hard-drive right in the root, or even in sub-directories, is the wrong way to go about this. I guarantee you that there would be people who would complain about these AppLocations directories that pop up without their consent. Contrast this with the fact that you wouldn't even have known that APPDIR: existed, and cached stuff unless someone had told you.

Well, first of all I'd want people to be fully informed about what the system does and also to be able to turn the applocations system off.
Then, if it's really such a big problem, then there could other solutions (beside the one I suggested above): f.ex., :Applocations could become :.applocations and the WB could be instructed to ignore it just like .backdrop; or :.applocations could be hidden at a lower level, just like it happens for .recycled on SFS (or somewhere else in between, if possible).

But, since you rightfully care about transparency, how about the fact that the applocations system allows totally transparent access to each executable? In practice, each and every executable becomes part of the command path, so that all that's needed is typing its name wherever/whenever needed. Isn't that the hightest degree of transparency when it comes to executing stuff? Isn't this a major advantage?

Quote:

APPDIR: does NOT interfere with the operation of the rest of the system,

Neither does the applocations system, in the sense you (seem to) mean here.

Quote:

or the way that the user set up his/her hard-drive.

OK, this has been discussed above.

Quote:

It requires no changes to applications or installers to support it; it's transparent to the rest of the system.

Same goes for the applocations system.

Quote:

Quote: I'd say it does more than the applocations would, as it involves additional tasks/processes, IPC and periodical mantainance (at least in its current form), whereas the applocations system only requires an additional feature in the filesystem that doesn't require any asynchronous operation. Have you noticed any performance hit? No, you haven't. It runs at priority -99, so it only works when the system has free CPU cycles to spare, i.e., when you're not using it. You're also making too many assumptions about how APPDIR is implemented.

I didn't say if affects performance in a noticeable manner: I said the applocations systems affects it even less (oh, well, of course this is an estimate).
And I'm not making assumptions about the APPDIR: functioning, as I publically talked with somebody (coliw) who explained how it works (it's in the very same discussion on Amigans.net you also partecipated to).


Quote:

Quote: False: I don't use it, but the moment some software not written by me starts using APPDIR:, it gets in my way. On the other hand, the applocations system is totally transparent and even more comfortable (not even something as short as "APPDIR:" needs to be specified anymore: the command name is all that's needed anytime anywhere). Come on, this is way too convoluted to be taken seriously. If some software uses it and it does its task, then you won't even notice that has happened. That's not "getting in your way;" it hasn't imposed anything on you; it's done its job.

The "I don't use it" implied "I disabled it" - I didn't think about specifying that because in these discussions I've repeatedly said that I'd like being able to turn it off, that I would turn it off and that I did turn it off (I guess that it's reasonable hoping that who is talking with me about this matters didn't miss that - please note that I'm not being sarcastic). So, it may get in my way - f.ex., if some application came with APPDIR:NotePad as default tool of its readme, I'd be given a "tool not found" error (whereas, with the applocations system, only "NotePad" would be needed and it would work for everybody - even for those who disabled the system and at least kept NotePad where it is by default, as that is (IIRC) in the path).

Quote:

And what if a file is transferred to a partition that doesn't support bidirectional links? Oops, everything falls over. APPDIR: could be made to handle this efficiently without having to make fundamental changes to the way that file-systems work (BLs can't just be tacked on).

Yes, that's a downside (that had already been discussed). In fact, the premise is that BLs should be implemented in the filesystems.
But, the point is: since what I'm suggesting is an improvement for a key functionality of the OS (namely, access to executables) and since BLs are a requirement, I'm of course also suggesting that BLs should be implemented in the OS' "own" filesystems, i.e. SFS and JXFS. Now, pray tell, who would put applications on a FFS/FAT/EXT3/whatever partition? And, even then, the existence of the "old" ways of accessing executables would still work.
In short, I'd say it's not a real problem.

Quote:

Quote: Sorry, but it seems you're missing the other shortcomings of APPDIR:, which have been exposed quite well in the other threads. I'm going to be blunt here, the "shortcomings" that I have read about are a joke.

Since you so easily address the remarks made (by me and several others) about the weaknesses of the current APPDIR:, I'll just as easily tell you that if AmigaOS had been written the same way, you'd have been using another OS for decades now

_________________
RETREAM - retro dreams for Amiga, Commodore 64 and PC

@Hans

Quote:

This is my final post on the matter. You'll just have to accept that I don't like your suggestion,

It's perfectly OK with me that you don't like my suggestion. But, from your previous post, it's evident that your opinion is influenced by some degree of misunderstanding, so I invite you to reflect on my suggestion when everything is clearer (as said, I'll make a post later that will give a better explanation of the system).

Quote:

and I disagree with your opinion about the APPDIR:.

From what you said, you underestimate the weaknesses of (the current implementation of) APPDIR:, so also your opinion about it is negatively influenced.

Quote:

I do not want to see yet another "solution" to the same problem.

Neither I want two solutions. I just offered an alternative: if it's better, then why not replacing APPDIR: with it; if it isn't, then let's forget about it. But what really counts is making a really serious, well-thought and open-minded evaluation of the two systems before taking a decision. I'm glad that this discussion brought a lot of food for thought: as a consequence, my original concept has been refined, and I have myself cleared my ideas about it. I still think that it's valid and that it could bring a few nice improvements to AmigaOS. Sure, I might be wrong - maybe BLs are not feasible, maybe my system isn't efficient as I think and who knows what else - but it'd be very sad if I'm right and still my suggestion was discarded because of misunderstanding, shallow evalution, personal feelings, etc.

_________________
RETREAM - retro dreams for Amiga, Commodore 64 and PC

@gregthecanuck

I'll answer later, no time now

EDIT

Here's the answer...

Quote:

The link idea was good but it has too many holes.

In my next post, where I'll make a clean recap of what has been said and done here, I'll deal with this.

Quote:

Clinging to the idea by suggesting bi-directional links is just making it worse.

You see, BLs are the key to achieve what I suggest. Without them, my system doesn't even work. They're not a personal fixation.

Quote:

I have made suggestions to deal with all the issues raised: - multiple versions - multiple alternates to same command - apps being moved/deleted

* multiple versions: I did reply (anyway, in short: the system does allow to handle that nicely - more explanations in the next post);
* multiple alternates to same command: the command Alias already happily handles that;
* apps being moved/deleted: a key feature of my system is precisely that it solves that problem - if this escaped you, then I'm afraid you haven't understood the applocations system at all.

Quote:

You have not. I'm done.

It looks like you haven't read or understood what I wrote.

Last edited by saimo on 21-Jan-2010 at 01:02 PM.

_________________
RETREAM - retro dreams for Amiga, Commodore 64 and PC

@saimo

Quote:

saimo wrote: The "I don't use it" implied "I disabled it" - I didn't think about specifying that because in these discussions I've repeatedly said that I'd like being able to turn it off, that I would turn it off and that I did turn it off (I guess that it's reasonable hoping that who is talking with me about this matters didn't miss that - please note that I'm not being sarcastic). So, it may get in my way - f.ex., if some application came with APPDIR:NotePad as default tool of its readme, I'd be given a "tool not found" error (whereas, with the applocations system, only "NotePad" would be needed and it would work for everybody - even for those who disabled the system and at least kept NotePad where it is by default, as that is (IIRC) in the path).

IMHO, the only point I could argue against such a feature as APPDIR: would indeed stand in not being possible to turn it off. And here, I do mean what you just said about the system not working properly anymore when APPDIR: feature is turned off.
But it seems easy to have "APPDIR:NotePad" mean "NotePad" for the system when the feature is turned off, as in APPDIR: would mean "Path" in such a case.

THE APPLOCATIONS SYSTEM


Overview and key features

The Applocations System ("AS", in short) is a set of mechanisms that allows extremely easy access to executables, regardless of where they are located. For example, one could type "browser" in a shell and get an Internet browser launched, or set the default tool of an icon to "viewer" and get the viewer application run, regardless of the actual location of the executables. With the AS, in short, the access to any executable is totally transparent and immediate.
Another key feature is that executables can be freely renamed or moved, remaining transparently accessible as they were before the operation.
Finally, the removal of executables is automatically and quickly handled, so that the system is never littered with leftovers.
The AS, in practice, extends and makes more powerful the commands path concept.


Requirements

The AS strictly requires the following:
* that the filesystem(s) executables reside on support Bidirectional Links (BLs from now on; BLs are links that can be accessed by the filesystem also starting from the file they link to);
* the presence of a directory called ".applocations" in the root of each volume containing executables that the user wishes to access through the AS;
* that the OS component that handles the commands path and launches executables ("executable launcher", from now on) considers the set of the .applocations directories in all the mounted volumes (part of) the default commands path.

The following would be highly desirable:
* BLs support in the command MakeLink;
* further extension of the "executable launcher" (more about this below).
* a GUI for a comfortable manual management of the AS (more about this below).


Basics of how it works

For each executable that is managed by the AS, a BL is present in the .applocations directory on the same volume.
When a path-less name of a file that is not in the current directory is passed to the system, the executables launcher searches for a match in the commands path and, if a BL is found, launches the linked executable.
If an executable is renamed/moved, the BL remains valid because, contextually to the operation, the filesystem updates also the reference to the linked file. Similarly, if an executable is removed, the corresponding BL gets removed automatically.


Including executables in the AS

The AS only handles those executables which have a BL in an .applocations directory, so there must be some way to create the BLs.
The first and lowest-level solution is adding support of BLs to the command MakeLink, so that it is possible to create the BLs manually.
The second is providing a GUI where the user can comfortably specify the executables.
The third is extending the executables launcher so that it automatically creates a BL whenever a "new" executable is run (after the user has given the authorization by means of either a global configuration setting or a choice in a requester presented on the fly by the executables launcher itself).
More automated solutions could be implemented with hooks at various levels (WB, DOS, etc.), but those choices should be taken carefully.
It would be desirable to offer the user also the possibility of specifying which executables not to include in the AS (he might want to minimize the number of BLs).


Miscellaenous notes and issues

BLs

BLs themselves would be a nice feature, as they could have other uses as well. The system strictly needs only BLs that can be linked only to a single file and viceversa, but more powerful BLs would of course be welcome.

The commands path

The commands path, other than the addition of all the .applocations directories, remains the same, so it may well include C:, S: and any other location (so that excluded executables can still be accessed transparently).
BLs are the key of the system, so if they are not feasible the system becomes totally useless.

Caching

Since executables accessed by means of BLs involve filesystem work, the executables launcher might use a cache (of user-defineable size) of the most recently accessed BLs.

Hiding of .applocations

If would desirable to offer the option of hiding the .applocations directories. Possible solutions:
* not to associate real icons to them, so that they never show in "show only icons" WB mode (this is warmly suggested anyway);
* instruct the WB to ignore them like .backdrop;
* hide them at a lower level (DOS, maybe?);
* extend the filesystem to support hidden directories (this would be a useful general-purpose feature).

Corrispondence of link and executable names

BLs, like other kinds of links, can be named indipendently from the name of the linked file. However, relatively to the AS, this power has also a downside, as shown by the following example. Let's assume that the executable "viewer", associated to the BL "viewer" gets renamed as "HyperViewer": the viewer remains accessible with "viewer" (which would seem a good thing, as references to "viewer" would remain valid), but the corrispondence between the BL and the executable, from a user/human point of view, has become weaker.
Ideally, when a executable is renamed, the user should be given the possibility of choosing also whether the corresponding BL has to be renamed or not. Which level to solve the problem at? It would be easy to extend the WB and shell command Rename so that they ask also the name for the link, but the problem would still show up in other applications. The only solution would be handling the problem at a lower level.
A clean solution is having (as a filesystem option) BLs that are renamed automatically like the linked file whenever the latter is renamed (please note that this does not mean that the user cannot rename at will just the link later). Such solution preserves the corrispondence, although it breaks previous references (f.ex. default tools - but, after all, it is pretty normal that references to a command are broken if the command name is changed).

Multiple executables

One might wonder what happens if there are multiple executables with the same name. Let's see what can be done with an example.
There are 3 executables named "convert" (say, in the directories "graphics/", "sound/" and "text/") and all of them should be included in the AS. A simple and good solution would be creating more meaningful BLs - f.ex., "graphics.convert", "sound.convert" and "text.convert" (the automated tools for creation of BLs should propose solutions of this kind and it would be good to have official guidelines about how to handle these cases).
Particular care has to be taken when executables are on different volumes, since the duplication does not appear when (re)naming BLs, but when executing commands: the problem can be solved by means of a request to the user from the executables launcher as soon as it detects a name duplication in the commands path.
A careful naming scheme for the BLs also helps a lot with handling different versions of the same executable (f.ex. "convert.old", "conver.new", "convert.1.2", etc.).

Other advantages

Besides its ease and flexibility of use, the AS has other advantages:
* it requires no sever/daemon;
* it is intrinsically robust as the coherency of the .applocations directories is guaranteed at the lowest level possible (i.e. the filesystem) in a synchronous manner;
* since BLs are local to the volumes, executables are transparently accessible from any machine which has the AS running on it; moreover, if executables are moved/renamed/deleted, even from a machine that does not have the AS, the .applocations directory stays coherent (f.ex., let's say that a certain editor, residing on a shared volume, is normally accessed from a machine using the command "editor" and that then somebody else changes the location of the editor from another machine: the editor will still be perfectly accessible by means of "editor");
* it is conceptually simple (the amount of issues above are due mostly to the nature of the matter it tackles, rather than to its design);
* it requires very little resources.

Drawbacks

The AS is not perfect. Here is a list of its drawbacks.

Drawback #1: it does not work with legacy filesystems like FFS, PFS, etc.
Food for thought: for how long will people use obsolete filesystems? Is it unreasonable to ask them to switch to the modern and officially supported ones, to benefit of the new features (of the filesystems themselves and of AS)?

Drawback #2: it does not work with non-Amiga filesystems like FAT, EXT3, etc.; it does not work on read-only media; it doesn't work on volumes that do not allow the creation of the .applocations directory.
Food for thought: is running executables from there common? Commonly used applications probably are not located in places that might be unreachable (which often is the case when it comes to removable media), or provide low performance, or are not formatted in an AmigaOS official filesystem. Moreover, since the purpose of the AS is reaching easily executables that are reliably reachable (and commonly used) within the whole system what would be the point of having any kind of shortcut at all? In general, what is the point of storing references to items whose presence in uncertain/unlikely? Is it really wise allowing incoherencies?

Last edited by saimo on 22-Jan-2010 at 09:24 AM.
Last edited by saimo on 22-Jan-2010 at 09:21 AM.
Last edited by saimo on 22-Jan-2010 at 08:47 AM.
Last edited by saimo on 21-Jan-2010 at 10:44 PM.
Last edited by saimo on 21-Jan-2010 at 06:31 PM.
Last edited by saimo on 21-Jan-2010 at 05:50 PM.
Last edited by saimo on 21-Jan-2010 at 04:32 PM.
Last edited by saimo on 21-Jan-2010 at 04:27 PM.
Last edited by saimo on 21-Jan-2010 at 04:20 PM.

_________________
RETREAM - retro dreams for Amiga, Commodore 64 and PC

@all

I hope the length of the post above won't discourage anybody from evaluating my proposal (by the way, pondering on the matter will help greatly improving APPDIR:, since it shares many issues with the applocations system - f.ex., how to create the references to the executables). Also, I hope the description is clear enough.
I'll update it whenever necessary, accordingly to the comments that will follow.

@Ball000

Quote:

IMHO, the only point I could argue against such a feature as APPDIR: would indeed stand in not being possible to turn it off. And here, I do mean what you just said about the system not working properly anymore when APPDIR: feature is turned off. But it seems easy to have "APPDIR:NotePad" mean "NotePad" for the system when the feature is turned off, as in APPDIR: would mean "Path" in such a case.

No, that's not what happens: if APPDIR: is turned off, to the system "APPDIR:" is simply a device name, so all the user gets, provided that Assign-Mount is enabled, is a requester saying "Hey, APPDIR: is not mounted: what should I do?".

Last edited by saimo on 21-Jan-2010 at 04:30 PM.

_________________
RETREAM - retro dreams for Amiga, Commodore 64 and PC

@saimo

Drawbacks

* It requires rewritting/modification in the filesystem itself as such it is "getting in the way" of users who don't want to use the filesystem you wrote (because of no evidence of reliablity) or modified (because you won't be able to modify every filesystem out there and every one has it's preference be it FFS2, SFS, SFS2, JXFS just to name the one natively available but I heard some braves are using PFS too for example).
* your solution does not work on network drive (because they are using Samba for example, and Samba does not support BL and never will),
* it does not work on read only medium (for example it can't cache executables from a CD-Rom),
* it does not work on USB drives/keys that are not reformatted using an Amiga BL aware filesystem (which is not so common on my part I only use FAT formatted USB devices for purpose of being able to do crossplatform exchanges)

_________________
AOS 4.1 : I dream it, Hyperion did it !
Now dreaming AOS 4.2...
Thank you to all devs involved for this great job !

@abalaban

Quote:

* It requires rewritting/modification in the filesystem itself as such it is "getting in the way" of users who don't want to use the filesystem you wrote (because of no evidence of reliablity) or modified (because you won't be able to modify every filesystem out there and every one has it's preference be it FFS2, SFS, SFS2, JXFS just to name the one natively available but I heard some braves are using PFS too for example).

As for writing to the filesystem: true, but then also APPDIR: requires writes. If you can think of a system that doesn't, it'd be just cool
As for reliabily: of course I'm not suggesting to introduce the AS before the modified filesystems are deeply tested and proven to be reliable.
As for filesystem preferences: mine is a suggestion for the future and restricted to just the "official" filesystems, which will naturally take the place of the old ones more and more as time goes by; I can hardly see anybody sticking to some old/esotic filesystem forever when, instead, the OS comes with its own advanced and maintained filesystems.
Finally, in general, should we always be so scared of innovating only because somebody is afraid of innovation and/or wants to stick to legacy without a real reason?

Quote:

* your solution does not work on network drive (because they are using Samba for example, and Samba does not support BL and never will), * it does not work on read only medium (for example it can't cache executables from a CD-Rom), * it does not work on USB drives/keys that are not reformatted using an Amiga BL aware filesystem (which is not so common on my part I only use FAT formatted USB devices for purpose of being able to do crossplatform exchanges)

This is all true, but, on the other hand, any system with the same purpose of AS (like APPDIR:) is based on the assumption that such executables are present in the system: what's the point of having a shortcut to an application whose presence is uncertain (if not unlikely)? It is indeed not recommendable to cache paths for applications stored in the places you suggest.
Moreover, how often does one launch applications over Samba, from USB keys, CDs, etc.?

_________________
RETREAM - retro dreams for Amiga, Commodore 64 and PC

@saimo

Quote:

As for writing to the filesystem: true, but then also APPDIR: requires writes. If you can think of a system that doesn't, it'd be just cool

unless I misunderstood your solution but you are suggesting to have a .applocation on each supported medias don't you ? So you requires write access to all of them while AppDir: only requires write access to one location (ENVARC:)

Quote:

As for filesystem preferences: mine is a suggestion for the future and restricted to just the "official" filesystems, which will naturally take the place of the old ones more and more as time goes by; I can hardly see anybody sticking to some old/esotic filesystem forever when, instead, the OS comes with its own advanced and maintained filesystems.

This is simply unrealistic see how you react to an unvital optionnal small utility feature think to how people will react when you'll announcethem you will touch to their filesystem and you will enforce them to switch to the filesystem you choosed...

Quote:

This is all true, but, on the other hand, any system with the same purpose of AS (like APPDIR:) is based on the assumption that such executables are present in the system: what's the point of having a shortcut to an application whose presence is uncertain (if not unlikely)?

After all we are on AmigaOS wouldn't it good to have a requester asking you to insert volume "MySuperdDuperCD:" when you try to run the installed part of your favorite game ?

Quote:

Moreover, how often does one launch applications over Samba, from USB keys, CDs, etc.?

Just because you don't do it, does mean noone needs it...

_________________
AOS 4.1 : I dream it, Hyperion did it !
Now dreaming AOS 4.2...
Thank you to all devs involved for this great job !

@abalaban

Quote:

unless I misunderstood your solution but you are suggesting to have a .applocation on each supported medias don't you ?

Just for clarity: The AS strictly requires [...] the presence of a directory called ".applocations" in the root of each volume containing executables that the user wishes to access through the AS;

Quote:

So you requires write access to all of them while AppDir: only requires write access to one location (ENVARC:)

Sorry, but you originally objected that the AS requires writes to disk and that the writes might not be reliable, so I answered to that. Now the fact that the writes happen in multiple directories is a different story. And my simple answer is: so what? Since the writes are reliable (they must be, otherwise it would be foolish to make the filesystem public in first place), what's problem?

Quote:

Quote: As for filesystem preferences: mine is a suggestion for the future and restricted to just the "official" filesystems, which will naturally take the place of the old ones more and more as time goes by; I can hardly see anybody sticking to some old/esotic filesystem forever when, instead, the OS comes with its own advanced and maintained filesystems. This is simply unrealistic see how you react to an unvital optionnal small utility feature think to how people will react when you'll announcethem you will touch to their filesystem and you will enforce them to switch to the filesystem you choosed...

You make it seem like my reaction to APPDIR: is exaggerated and unjustified, but it's not: the feature, as of now, is not officially optional, suffers from some problems (there are a few threads that talk about them, so I won't repeat them here) and is not useful to me. I'm pointing this out only because that's much different from refusing to update a system with modern and fully working components, with a large variety of benefits. Asking people to replace unsupported stuff with modern and official components is just reasonable in general (regardless of the AS, I mean). Legacy can't stop evolution forever.
Please also keep in mind that I'm not asking for things to happen tomorrow: mine is a proposal for the future. And, above all, at the moment of its introduction I wouldn't want it to be enforced on users.

Quote:

Quote: This is all true, but, on the other hand, any system with the same purpose of AS (like APPDIR:) is based on the assumption that such executables are present in the system: what's the point of having a shortcut to an application whose presence is uncertain (if not unlikely)? After all we are on AmigaOS wouldn't it good to have a requester asking you to insert volume "MySuperdDuperCD:" when you try to run the installed part of your favorite game ?

Yes, sure, but the main point still stands: what's the point of caching references to executables whose presence is uncertain? Moreover, also consider that the fact alone that an application is not "permanently installed" is a sign that the user does not need it often: it certainly isn't the kind of application that the user needs to access from several places like shell, WB, menus, other applications and so on, thus needing the transparent access that AS (or any other similar mechanism) offers - for that application, most likely an icon in AmiDock, an entry in a menu, an alias or maybe just a simple direct access (open volume and click icon) is more than enough.
Finally, please note that APPDIR: removes invalid references as well (although periodically).

Quote:

Quote: Moreover, how often does one launch applications over Samba, from USB keys, CDs, etc.? Just because you don't do it, does mean noone needs it...

I didn't say that since I don't have that need and so nobody does. I was just asking, because, you know, we're having a discussion that's how it's supposed to work
(As for the issue itself, it is already covered above.)

Last edited by saimo on 21-Jan-2010 at 10:47 PM.
Last edited by saimo on 21-Jan-2010 at 06:47 PM.

_________________
RETREAM - retro dreams for Amiga, Commodore 64 and PC

@saimo

Quote:

Sorry, but you originally objected that the AS requires writes to disk and that the writes might not be reliable, so I answered to that. Now the fact that the writes happen in multiple directories is a different story. And my simple answer is: so what? Since the writes are reliable (they must be, otherwise it would be foolish to make the filesystem public in first place), what's problem?

No I was objecting that you require special mechanism in the filesystem for this to work not the fact you are writing to disk (which obviously is needed when one is doing a cache of some sort). Now the problem is you also require to have write access to media in order to cache things that are located on them...

Quote:

You make it seem like my reaction to APPDIR: is exaggerated and unjustified, but it's not: the feature, as of now, is not officially optional, suffers from some problems (there are a few threads that talk about them, so I won't repeat them here) and is not useful to me. I'm pointing this out only because that's much different from refusing to update a system with modern and fully working components, with a large variety of benefits. Asking people to replace unsupported stuff with modern and official components is just reasonable in general (regardless of the AS, I mean). Legacy can't stop evolution forever. Please also keep in mind that I'm not asking for things to happen tomorrow: mine is a proposal for the future. And, above all, at the moment of its introduction I wouldn't want it to be enforced on users.

I personnaly don't see any problem in the current APPDIR: implementation. About your thoughts concerning legacy and evolution I totally agree with you.

Quote:

Yes, sure, but the main point still stands: what's the point of caching references to executables whose presence is uncertain? Moreover, also consider that the fact alone that an application is not "permanently installed" is a sign that the user does not need it often: it certainly isn't the kind of application that the user needs to access from shell, from WB, from menus, from other applications and so on, thus needing the transparent access that AS (or any other simililar mechanism) offers - for that application, most likely an icon in AmiDock, an entry in a menu, an alias or maybe just a simple direct access (open volume and click icon) is probably more than enough. Finally, please note that APPDIR: removes invalid references as well (although periodically).

The point is that because they are "unstable" or not used very often they are *required* to be in the AppDir: because chances are high that commands you are using all the time you know their location while this won't be the case for occasionnally used softwares. In fact I miss one thing in AppDir : a way to configure the retaining delay (and augmenting it from one month to one year)

Quote:

I didn't say that since I don't have that need and so nobody does. I was just asking, because, you know, we're having a discussion that's how it's supposed to work

Yes it wasn't meant to be aggressive sorry if it sounded like that. For example I have a NAS at home and my dev projects are on it, as a consequence I frequently execute programs from a Samba mounted drive (but I generally remember where they are because I juste finished compiled them prior to their execution

_________________
AOS 4.1 : I dream it, Hyperion did it !
Now dreaming AOS 4.2...
Thank you to all devs involved for this great job !

@abalaban

Quote:

No I was objecting that you require special mechanism in the filesystem for this to work not the fact you are writing to disk (which obviously is needed when one is doing a cache of some sort). Now the problem is you also require to have write access to media in order to cache things that are located on them...

As I said multiple times, yes, BLs are a requisite: quite simply, if, for whatever reason, they are not feasible, the AS can be put aside; if they are, the AS become doable. Moreover, I have to repeat that BLs are a nice general-purpose feature that could find other interesting uses.

As for having write access to the media: yes, that's another requisite and, yes, sometimes it's a disadvantage. However, again I have to wonder: how often? Moreover, it has also a few nice sides: since BLs are local to the volume, executables are transparently accessible from any machine which has the AS running on it; moreover, if executables are moved/renamed/deleted, even from a machine that does not have the AS, the .applocations stays coherent - f.ex., let's say that you run a certain editor, residing on a removable HD, from your machine using the command "editor" and that then somebody else mounts the same HD on another machine and changes the location of the editor: the next time you attach the HD to your machine, the editor will still be perfectly accessible by means of "editor". Or, even better, think of how handy this could be with network-shared drives...

Quote:

I personnaly don't see any problem in the current APPDIR: implementation.

It might suffice to you, no questioning. But it does have problems (I won't go into details because it would OT and because there are other threads dealing with the matter).

Quote:

The point is that because they are "unstable" or not used very often they are *required* to be in the AppDir: because chances are high that commands you are using all the time you know their location while this won't be the case for occasionnally used softwares. In fact I miss one thing in AppDir : a way to configure the retaining delay (and augmenting it from one month to one year)

Yes, sure, ideally that's one more reason for having always the same shorcut, but practically you are suggesting the introduction of forced cache incoherency to handle just a minority of cases. Cache incoherency is in general something to be avoided, as it might (and usually does) end up firing back in a number of unforeseen ways. For the specific need you're talking about, I'd avoid breaking a mechanism like that of APPDIR:, AS or whatever other system, and I'd just use "classic" shortcuts like an Alias, a link, etc.

Quote:

Yes it wasn't meant to be aggressive sorry if it sounded like that. For example I have a NAS at home and my dev projects are on it, as a consequence I frequently execute programs from a Samba mounted drive (but I generally remember where they are because I juste finished compiled them prior to their execution

Ah, wait, last night I realized an incorrect thing has been said and tacitly accepted: it's not true that the AS does not work with Samba (or over a network) in general. As we just said, the AS requirements are that the filesystem(s) involved must offer BLs and allow writing: whether the volumes are inside the case of one's machines or at the other end of the world doesn't make any difference

Last edited by saimo on 22-Jan-2010 at 09:14 AM.

_________________
RETREAM - retro dreams for Amiga, Commodore 64 and PC