IMPORTANT

A clean description of the system introduced below and discussed in this thread is given in the post #33.

***

The recent discussion about APPDIR: brought me to a conclusion so simple and effective that I wonder if I'm just being too naive - it could be, so don't be afraid to burst my bubble.

What am I talking about? I'm talking about a radical solution to a problem that every OS designer has faced in his a life, the problem that both the command path and the APPDIR: device try to solve: namely, allowing executables to be located anywhere and yet making them immediately reachable.
My solution is very, very simple, and so (hopefully) will be its explanation.

Let's start from the objective: wouldn't it be nice if all commands/applications could be reached through a single, fixed path, regarless of their location and any rename/move operation? Since we're in Amigaland, let's say that such place is SYS:Applocations (anybody's welcome to come up with a better name). Whenever a pathless command is issued, all the system would need to do is looking into SYS:Applocations. Of course we're in Amigaland, so I'm not talking about placing all the executables there - as said, instead, the objective is letting users put their executables wherever they please and move them around freely. So, SYS:Applocations would only keep references to the actual executables.
What's the difference with APPDIR:? - you might ask. Conceptually, none, indeed. The difference is that the implementation I propose does not cause any coherency problem and does not require any complex mechanism. My implementation needs only one little thing that AmigaOS still doesn't have. AmigaOS only needs some Big Love... erm... Bidirectional Links. I'm sure many Amigans have already understood my solution now
What would be a BL? It's a normal soft link with the addition that a reference to the link is associated to the linked file, so that any time the file is moved/renamed/deleted, the filesystem can update accordingly also the link. I'm tempted to delve into the issues of BLs, but I don't want to shift the focus from the objective, to which I return immediately.
Well, all that's left to say is obvious: the entries in SYS:Applocations would be simple BLs to the executables (for convenience, let's call these entries applocations).

Let's make a list of the advantages:
* no more need to specify paths for commands at any level;
* users can move/rename/delete executables at will;
* coherency is automagically guaranteed at filesystem level;
* the OS becomes simpler (command path and APPDIR: can be forgotten) and more efficient (quick and easy access to executables);
* BLs could (and probably will) turn out to be useful for other purposes, too.

Potential issues: well, I'm so dazzled by the simplicity and elegance of this solution that I must admit I can't think of many problematic issues. The fact that nobody, AFAIK, has thought about it before makes me fear there must be a pitfall somewhere. Maybe BLs aren't that easy to implement (I can't see why, but I'm not filesystem expert either)? Maybe the large number of applocations could cause problems to the filesystem - are we still fighting against tight limitations? Would breaking them be hard? Maybe scanning that single location would be inefficient - but isn't processing the command path just as hard? Would caching mechanisms hard to implement? Is there anything else I can't see (and I'd be surprised if not)?

Final note: I haven't dealt with the policies for creating the applocations because that's a secondary issue. Anyway, for completeness' sake, I'd suggest to offer a number of ways: pre-defined applocations (f.ex., all system commands should be mapped by default), optional automatic applocations (created on the fly when the user launches a command the first time, if he/she has enabled such feature) and explicitly user-defined applocations.

Please share your thoughts.


EDIT

The ensuing discussion provided some precious input and allowed the refinement of the original idea in order to make it easier to implement and more robust. Specifically, the idea should be extended this way: there should not be a single SYS:Applocations directory, but instead each volume should have its own :Applocations directory and the system should implicitly treat the set of the :Applocations directories in all the mounted volumes as the (base) command path.

Last edited by saimo on 22-Jan-2010 at 09:48 AM.
Last edited by saimo on 21-Jan-2010 at 04:07 PM.
Last edited by saimo on 21-Jan-2010 at 04:07 PM.
Last edited by saimo on 21-Jan-2010 at 04:06 PM.
Last edited by saimo on 20-Jan-2010 at 06:11 PM.
Last edited by saimo on 20-Jan-2010 at 06:02 PM.

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

@saimo

it doesnt solve the main problems with appdir
- how is the link put there in the first place?
- which version of the program is run if several is installed?
- which program is run if several applications have similar names?
- when are they removed if the application is removed?

what you are suggesting is exactly the same as appdir with bi-directional links. so instead of this whole "new great idea" just add those to appdir and you'd be just as good off.

/stone

@stone

Quote:

- how is the link put there in the first place?

See the final note in the original post.

Quote:

- which version of the program is run if several is installed? - which program is run if several applications have similar names?

Thanks for asking - I forgot to talk about that in the original post.
Quite simply, applocations can have any name - they don't need to be named just like the executables they're linked to. F.ex., if you have multiple versions of the same executable (called "myapp"), the corresponding applocations could be "myapp", "myapp-old" and so on (the user would be free to decide the naming, although it would be good to define an official guideline).

Quote:

- when are they removed if the application is removed?

Exactly at the same time - it's the filesystem that handles that.

Last edited by saimo on 20-Jan-2010 at 10:53 AM.

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

@saimo

- having to execute it to put it there is counter-intuitive and a certain way to problems. just like with appdir. you havnt actually solved that problem.
- its fine that users can make their own links, but that should be doable in appdir too already. however, the system needs to _automatically_ handle that i click one program called "myapp" then another with the same name. and _then_ launch the right one when i try to open a file associated with it. appdir doesnt handle that, neither do you.
- and if you remove the link when the executable is deleted, then what program will open my file? how is the similar named "myapp" going to deal with the link now being gone?

you havnt actually solved any of appdir' problems, and yes, its _exactly_ like appdir, save the name and the bi-links. its not a different implementation just because you change the name.

/stone

Last edited by stone on 20-Jan-2010 at 11:00 AM.

@saimo

Quote:

Potential issues: well, I'm so dazzled by the simplicity and elegance of this solution that I must admit I can't think of many problematic issues. The fact that nobody, AFAIK, has thought about it before makes me fear there must be a pitfall somewhere. Maybe BLs aren't that easy to implement (I can't see why, but I'm not filesystem expert either)? Maybe the large number of applocations could cause problems to the filesystem - are we still fighting against tight limitations? Would breaking them be hard? Maybe scanning that single location would be inefficient - but isn't processing the command path just as hard? Would caching mechanisms hard to implement? Is there anything else I can't see (and I'd be surprised if not)?

The biggest problem is crossing volume boundaries.

If your file and link are both on (say) the filesystem on DH0:, then it's easy enough - the filesystem in question just needs a slight change to keep a linked list of blocks that keep references to links that needs to be updated on a rename. More space efficient (but more complex) mechanisms can easily enough be added.

You can also solve this by doing some of what POSIX compliant filesystems do for hardlinks: Instead of making the link bidirectional, you make them "weak" hardlinks (as a parallel to weak references in OO programming): Point to a header block for the file instead of by name. Add a usage count to the header block.

When moving the file or a weak hardlink, just move the directory entry - the file doesn't move. When deleting the file, if the link count is greater than 1, keep the header block (since you don't know who points there) but free everything else. Next time the weak link is dereferenced, you act as if the file is completely gone. This has the benefit of not needing to keep a list of inbound links (but this may be false economy if most files have just one link), but the downside that you need to keep the header block around ("proper" POSIX hardlinks on the other hand keep the whole file around until the count drops to zero)

BUT: If you limit it to the same volume, why can't you just reverse the link? I.e. put the file in Sys:Applications or wherever, and link to it from anywhere else you want it to appear. The effect is pretty much the same.

If they're *not* on the same volume, what happens if one of the volumes is removed, or moved to another machine and changed? For most things that might be rare, and it might not be a big deal, but the semantics need to be clear. I.e.: Do you "break" the link? Do you turn it into a symlink? Do you try to keep it consistent across volumes with some sort of mechanism to update it when the volume is reattached?

It also complicates the implementation in other ways since it doesn't necessarily involve just a single filesystem driver anymore.

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

@saimo

Quote:

SYS:Applocations (anybody's welcome to come up with a better name)

I reckon SYS:Applications would be better!

Sorry, couldn't resist!

Edit: Haha, made a right fool out of myself there... I thought you'd simply mis-spelled the word Applications, however it seems you meant AppLocations! Oops, my bad

Last edited by Slash on 20-Jan-2010 at 11:22 AM.

_________________
This fire is burnin' and it's out of control
It's not a problem you can stop, It's rock n' roll - GN'F'N'R

@stone

Quote:

- having to execute it to put it there is counter-intuitive and a certain way to problems. just like with appdir. you havnt actually solved that problem.

Getting an applocation created automatically upon execution is only one possibility. As said, the user should also be given the possibility of managing the applocations directly (well, all that would be strictly needed is an extended version of the MakeLink command, although a GUI would be nice);

Quote:

- its fine that users can make their own links, but that should be doable in appdir too already.

So what?

Quote:

however, the system needs to _automatically_ handle that i click one program called "myapp" then another with the same name. and _then_ launch the right one when i try to open a file associated with it. appdir doesnt handle that, neither do you.

First off, file type recognition is a different thing. We have DefIcons for that (and, if you don't like it, feel free to propose a different solution). The applocations mechanism, as explained, serves another purpose (it's written clearly the original post).
However, let me stress that the fact that there is a centralized place where all executables references are stored (SYS:Applocations) makes it easy to guarantee that always the desired command is executed thanks to the uniqueness of the applocations - and this is very helpful when defining default tools.

Quote:

- and if you remove the link when the executable is deleted, then what program will open my file? how is the similar named "myapp" going to deal with the link now being gone?

Please note that with any other mechanism the user would be left alone in the dark and also note that this is a file type recognition issue.
That said, with the applocation system, one could have a supervisor process (which belongs to the file types recognition system, not the applocations one) that is notified of deletions: this process could then search for similarly named applocations and propose the user whether to switch to a different application.

Quote:

you havnt actually solved any of appdir' problems, and yes, its _exactly_ like appdir, save the name and the bi-links. its not a different implementation just because you change the name.

It looks like you haven't understood my solution well enough. Please ponder on it a little longer.
Also, please avoid making confusion with file types recognition: it's better for everybody if this discussion stays focused on its subject.

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

I disagree with using links - too many potential problems.

If a user moves an executable the file notification system should be APPDIR: aware and automatically update the appdir info. Similarly, if an executable is deleted automagically nuke the appdir info via notification.

As for installing multiple versions of an executable, that gets a bit trickier. My thoughts on this for now are:

1. use executable versioning
2. most recent version encountered becomes default
3. if old version still exists on disk this can be taken two ways:
- ignore it
- make appdir smarter to look to version info on request
i.e. if you say "APPDIR:myprog" it runs most recent
if you say "APPDIR:myprog version 3.14" this looks for version 3.14
4. if multiple different implementations of the same command exist, handle
that with "root" pointers?
- if you say "APPDIR:myprog root DEV:" this looks for myprog anywhere on DEV:
- if you say "APPDIR:myprog root SYS:C" this looks in SYS:C down
if a root points to more than one version the command should fail

5 minute brain-dump. Feel free to shred.

@vidarh

Quote:

The biggest problem is crossing volume boundaries. If your file and link are both on (say) the filesystem on DH0:, then it's easy enough - the filesystem in question just needs a slight change to keep a linked list of blocks that keep references to links that needs to be updated on a rename. More space efficient (but more complex) mechanisms can easily enough be added. You can also solve this by doing some of what POSIX compliant filesystems do for hardlinks: Instead of making the link bidirectional, you make them "weak" hardlinks (as a parallel to weak references in OO programming): Point to a header block for the file instead of by name. Add a usage count to the header block. When moving the file or a weak hardlink, just move the directory entry - the file doesn't move. When deleting the file, if the link count is greater than 1, keep the header block (since you don't know who points there) but free everything else. Next time the weak link is dereferenced, you act as if the file is completely gone. This has the benefit of not needing to keep a list of inbound links (but this may be false economy if most files have just one link), but the downside that you need to keep the header block around ("proper" POSIX hardlinks on the other hand keep the whole file around until the count drops to zero)

I have to admit I haven't followed the technical details - I'm no filesystem expert. But to me it looks like you're talking about hardlinks, whereas I'm suggesting the usage of softlinks (which, by the way, work perfectly also across different volumes): if a softlink can be defined one way, why can't it be defined also the other way? Sure, it needs some work at filesystem level, but to me it looks like it's feasible.

Quote:

BUT: If you limit it to the same volume, why can't you just reverse the link? I.e. put the file in Sys:Applications or wherever, and link to it from anywhere else you want it to appear. The effect is pretty much the same.

I don't want to limit the system to just one volume. Anyway, the effect wouldn't be the same at all, as coherency wouldn't be guaranteed and executables often assume that the directory they reside on also contains other data.

Quote:

If they're *not* on the same volume, what happens if one of the volumes is removed, or moved to another machine and changed? For most things that might be rare, and it might not be a big deal, but the semantics need to be clear. I.e.: Do you "break" the link? Do you turn it into a symlink? Do you try to keep it consistent across volumes with some sort of mechanism to update it when the volume is reattached?

Whenever the filesystem is informed that its volume is being removed, it should delete all the BLs (both ways, of course, and only if the user agrees to that).
If no clean umounting is performed - this is the worst case - whenever invalid entries are found in SYS:Applocations (by means of periodical checks, manual cleanup and when applocations are requested), they should be removed (informing the user, of course).
As for re-attachments, I wouldn't care much about that: applications are usually located on fixed volumes and, anyway, applocations can be re-created at any time.

Quote:

It also complicates the implementation in other ways since it doesn't necessarily involve just a single filesystem driver anymore.

Of course a requirement is that the filesystem each application is on must support BLs - if it doesn't, then simply the application doesn't get "indexed" in SYS:Applocations.

Last edited by saimo on 20-Jan-2010 at 01:24 PM.
Last edited by saimo on 20-Jan-2010 at 12:01 PM.
Last edited by saimo on 20-Jan-2010 at 12:00 PM.

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

@Slash

Quote:

I reckon SYS:Applications would be better! Sorry, couldn't resist! Edit: Haha, made a right fool out of myself there... I thought you'd simply mis-spelled the word Applications, however it seems you meant AppLocations! Oops, my bad

No problem

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

@gregthecanuck

Quote:

I disagree with using links - too many potential problems. If a user moves an executable the file notification system should be APPDIR: aware and automatically update the appdir info. Similarly, if an executable is deleted automagically nuke the appdir info via notification.

Erm... sorry, but it looks like the key concepts of the applocations system aren't clear to you - in fact, those links precisely avoid notifications and the need for APPDIR: altogether.

Quote:

1. use executable versioning 2. most recent version encountered becomes default 3. if old version still exists on disk this can be taken two ways: - ignore it - make appdir smarter to look to version info on request i.e. if you say "APPDIR:myprog" it runs most recent if you say "APPDIR:myprog version 3.14" this looks for version 3.14 4. if multiple different implementations of the same command exist, handle that with "root" pointers? - if you say "APPDIR:myprog root DEV:" this looks for myprog anywhere on DEV: - if you say "APPDIR:myprog root SYS:C" this looks in SYS:C down if a root points to more than one version the command should fail 5 minute brain-dump. Feel free to shred.

All suggestions are welcome: just make sure the system doesn't take decisions automatically without the user having given permission

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

Quote:

saimo wrote: @gregthecanuck Quote: I disagree with using links - too many potential problems. If a user moves an executable the file notification system should be APPDIR: aware and automatically update the appdir info. Similarly, if an executable is deleted automagically nuke the appdir info via notification. Erm... sorry, but it looks like the key concepts of the applocations system aren't clear to you - in fact, those links precisely avoid notifications and the need for APPDIR: altogether. Quote: 1. use executable versioning 2. most recent version encountered becomes default 3. if old version still exists on disk this can be taken two ways: - ignore it - make appdir smarter to look to version info on request i.e. if you say "APPDIR:myprog" it runs most recent if you say "APPDIR:myprog version 3.14" this looks for version 3.14 4. if multiple different implementations of the same command exist, handle that with "root" pointers? - if you say "APPDIR:myprog root DEV:" this looks for myprog anywhere on DEV: - if you say "APPDIR:myprog root SYS:C" this looks in SYS:C down if a root points to more than one version the command should fail 5 minute brain-dump. Feel free to shred. All suggestions are welcome: just make sure the system doesn't take decisions automatically without the user having given permission

I like discussions like this. I'm going to bed soon so won't be able to reply for a while.

I don't like links for a couple of reasons:
- they aren't handled nicely in things like directory listers - how do you know the file is a link and what it is pointing to?
- they can't store any attributes - they are "dumb"
- they are a rather esoteric feature (hard/soft)
- I don't know how mature link support really is in OS4 and the various filesystems - any "gotchas" lurking?

Rather store the app info in an XML file in appdir. This makes it infinitely expandable, viewable by a typical user, manageable in scripts, etc...

Cheers!

@gregthecanuck

Quote:

I don't like links for a couple of reasons: - they aren't handled nicely in things like directory listers - how do you know the file is a link and what it is pointing to?

I have a few objections:
* in general, refraining from introducing good technologies only because pre-existing applications don't know how to handle them properly yet does not seem a smart move to me;
* handling links correctly is not that hard (in fact, even the infamous WB is already capable of following them correctly);
* links already exist, so nothing would change for applications;
* it is possible to see what a link points to (either follow it or use the List command);
* even if you don't like and don't want to use links, with the applocations system all links would be stored in SYS:Applocations and would be used transparently (that's the point).

Quote:

they can't store any attributes - they are "dumb" - they are a rather esoteric feature (hard/soft)

They're not that esoteric at all

Quote:

- I don't know how mature link support really is in OS4 and the various filesystems - any "gotchas" lurking?

My proposal is about introducing a new kind of linking, which of course must be thought over thoroughly and implemented properly.

Quote:

Rather store the app info in an XML file in appdir. This makes it infinitely expandable, viewable by a typical user, manageable in scripts, etc...

You're thinking of file types recognition here: it's a whole different story...

Last edited by saimo on 20-Jan-2010 at 01:03 PM.

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

@saimo

Quote:

I have to admit I haven't followed the technical details - I'm no filesystem expert. But to me it looks like you're talking about hardlinks, whereas I'm suggesting the usage of softlinks (which, by the way, work perfectly also across different volumes)

"True" hardlinks as implemented in POSIX compliant file systems for example work exactly as a normal file. That is, when the file is deleted via one name, the file is *still available* via any other names.

What I suggested was a weaker guarantee - halfway in between a normal soft link and a proper hard link. Instead of pointing by name, you'd point by reference like for a hard link, but instead of keeping the entire file in case of deletion, you keep only the target of the reference.

The result is the *behaviour* of a softlink with automatic update (i.e. a bidirectional softlink) but with a very simple / fast implementation (just update a reference counter in the header block when adding/removing a link, and remove the file if it reaches zero, while still allowing deleting the file through it's "real" name to delete the file contents - just not the header block).

It's just a possible implementation strategy for what you're suggesting (though within a single volume only), that doesn't require updating possibly a large number of links when moving a file.

Quote:

: if a softlink can be defined one way, why can't it be defined also the other way? Sure, it needs some work at filesystem level, but to me it looks like it's feasible.

IF you can guarantee that there will never be many links to a single file OR you accept the performance overhead, then implementing it as normal softlinks with a list of the link locations tied to the file is perfectly fine.

The method I outlined above doesn't have that restriction, but at the cost of keeping a header block (or a table for a level of indirection) around until all links are removed. They are just different implementation tradeoffs - the user visible semantics would be exactly the same.

Quote:

Whenever the filesystem is informed that its volume is being removed, it should delete all the BLs (both ways, of course).

But this can happen when the system is off, so any filesystem supporting this would need to check all bidirectional links every time they are mounted. This also has the problem that if filesystems are mounted in the wrong order, links would get deleted. And since you would be able to have links in both direction between two different volumes, there might not even *be* a right direction, so you'd need to have rules for deferring the check. And what if the removal was accidental? Suddenly a bunch of links disappear.

Quote:

As for re-attachments, I wouldn't care much about that: applications are usually located on fixed volumes and, anyway, applocations can be re-created at any time.

The problem is that things that are "usually" true tend to have a significant chance of being false for a large number of people at just the wrong moment. Imagine one of your harddisks dying. Before you get a chance to restore from backup, all your links are suddenly gone.

And if applocations can be recreated at any time, why would you even need bi-directional links? You could then just have the system regularly go through the recreation steps using symlinks.

Quote:

Of course a requirement is that the filesystem each application is on must support BLs - if it doesn't, then simply the application doesn't get "indexed" in SYS:Applocations.

That isn't the issue. If it's a single filesystem, then that filesystem has full control of how data is stored. If it needs to span multiple fileystems, then regardless of implementation method it means there needs to be notification across the filesystem boundaries, or the bidirectional links need to be implemented "above" the filesystem layer (i.e. in dos.library) and the filesystems need to expose API's to carry out the notification and update of links via dos. This is more complicated than implementing it as a mostly transparent features in the filesystem drivers.

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

@gregthecanuck

Quote:

- they are a rather esoteric feature (hard/soft)

I have dear memories from my childhood of teasing PC people with the lack of links in DOS and later Windows. It was hardly esoteric 20 years ago - all the kids I knew were aware of and used symlinks -, even though I was ignorant of their long history in Unix (i.e. they've been around since the 70's) at that point. It's even less esoteric now, with MacOS and Windows having caught up (and bypassed in the case of MacOS, which has "aliases" which actually are bidirectional, but only within the same volume)

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

@vidarh

Quote:

... It's just a possible implementation strategy for what you're suggesting (though within a single volume only), that doesn't require updating possibly a large number of links when moving a file.

I appreciate you're spending energies to discuss about the filesystem implementation details, but honestly I don't care about how the BLs are implemented: to me, it's enough to know that who will take care of them is competent and that the job will be done the right way
Here I just want to propose a way to deal with executables, and linking happens to be a means to achieve it - that's why I just considered/mentioned only some functional aspects of them in the original post.
Of course, feel free to discuss all the technical details you want: for sure what you say could be useful to who is / will be interested in the implementation

Quote:

IF you can guarantee that there will never be many links to a single file

Yes, what I have in mind is precisely a 1:1 correspondence.

Quote:

OR you accept the performance overhead, then implementing it as normal softlinks with a list of the link locations tied to the file is perfectly fine.

Links handling performance is of course a issue I'm concerned about, but, like all the other implementation details, I leave that to the experts. To me, here it's sufficient to know whether what I propose is feasible or not.

Quote:

But this can happen when the system is off, so any filesystem supporting this would need to check all bidirectional links every time they are mounted. This also has the problem that if filesystems are mounted in the wrong order, links would get deleted. And since you would be able to have links in both direction between two different volumes, there might not even *be* a right direction, so you'd need to have rules for deferring the check. And what if the removal was accidental? Suddenly a bunch of links disappear.

These are serious issues for sure. My initial answer was a bit rushed, indeed; in fact, later, I edited it and added this key comment: "and only if the user agrees to that". Honestly, by then I had already reconsidered automatic removal of invalid links, but I did not scratch the idea entirely to let the user free of defining the behaviour of his system.

Quote:

The problem is that things that are "usually" true tend to have a significant chance of being false for a large number of people at just the wrong moment. Imagine one of your harddisks dying. Before you get a chance to restore from backup, all your links are suddenly gone.

True as well. But, you know, these matters don't have a real solution: there must be some compromise at some point. What really matters is that the user is given all the possible tools and choices to deal with broken links and that broken links don't affect the system besides the annoyance of having to fix/remove them when some exceptional event happens.

Quote:

And if applocations can be recreated at any time, why would you even need bi-directional links? You could then just have the system regularly go through the recreation steps using symlinks.

Because re-creating them costs and to ensure coherency - that's the core of the system (which otherwise would be perfectly identical to APPDIR:). F.ex., if I had a simple link in SYS:Applocations and renamed the linked file, the next time around the link in SYS:Applocations is accessed it would be invalid and thus require mantainance. With BLs that problem (the key one, IMHO) is avoided.

Quote:

That isn't the issue. If it's a single filesystem, then that filesystem has full control of how data is stored. If it needs to span multiple fileystems, then regardless of implementation method it means there needs to be notification across the filesystem boundaries, or the bidirectional links need to be implemented "above" the filesystem layer (i.e. in dos.library) and the filesystems need to expose API's to carry out the notification and update of links via dos. This is more complicated than implementing it as a mostly transparent features in the filesystem drivers.

I was precisely thinking of communication between filesystems: if I'm not wrong, there are already tasks/handlers/servers (I don't know the exact name, sorry) associated to them, so they could well communicate. But I'd be happy also with an implementation at a higher level, as long as it fully provides BLs with the specified key characteristics.

Last edited by saimo on 20-Jan-2010 at 03:20 PM.
Last edited by saimo on 20-Jan-2010 at 02:06 PM.
Last edited by saimo on 20-Jan-2010 at 02:00 PM.

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

@saimo

This guy is an expert - if you want, just ask him about your solution:

http://radio.weblogs.com/0100490/stories/2002/08/24/prebindingExplained.html

_________________
Sometimes we give people a lot of credit just because they're writing nice sentences even if it isn't adding up to much.

@Birbo

Quote:

This guy is an expert - if you want, just ask him about your solution: http://radio.weblogs.com/0100490/stories/2002/08/24/prebindingExplained.html

Thanks for the suggestion but, well, before hunting down people outside of Amigaland (and having to explain them the details about the Amiga environment in general), since the discussion has just started, I'd prefer to hear more about the the people in this community (techminds and simple users alike) - and, after all, it's not that we don't have experts either: vidarh seems to be quite well-educated and then we have Joerg (the man behind SFS and, if I'm not wrong, JXFS).
Moreover, I'm firstly interested in hearing the Amigans' opinion about the applocations system concept and then I'm not personally interested in the fine details of filesystems: to me, a simple "it is / is not possible [because of X]" (where "[because of X]" doesn't dive too much into the deep) is sufficient.
Maybe the time of resorting to external minds will never come...

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

@saimo

Quote:

Yes, what I have in mind is precisely a 1:1 correspondence.

Ok, that, to me means that you're more or less describing something that is better handled with the AppDir: solution of a separate task that receives notifications, combined with a device that handles the dereferencing.

The reason I don't think a link is appropriate if you require a 1:1 correspondence for bidirectional links is that it would make bidirectional links behave significantly differently from other links (where you can have many links), most executables would be impossible to add a bidirectional link for to anything but SYS:AppLocations, since there'd already be one pointing there (and if the user *were* to manage to add a link elsewhere, adding a link from SYS:AppLocations would mean you'd have to delete the users own link), and the restriction at the same time makes the AppDir: solution work fine.

As far as I can see, what you are proposing could in that case be handled just by changing the mechanism used to notify the task that updates the AppDir settings - no need to touch any of the filesystems. I.e. if the mechanism was changed to be triggered by an explicit action by the user, and the system tracked renaming/moving files. It's probably a far simpler change than adding "proper" bidirectional links.

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

@vidarh

Quote:

Ok, that, to me means that you're more or less describing something that is better handled with the AppDir: solution of a separate task that receives notifications, combined with a device that handles the dereferencing.

This would require the APPDIR: server to request notification for each and every executable managed: is this feasible? How much would it cost? How would it compare in robustness and performance with respect to links? Maybe it's worth making a deep evaluation/comparison of the systems (again, I'm just providing food for thought, what I'm really interested in is the final answer).

Quote:

The reason I don't think a link is appropriate if you require a 1:1 correspondence for bidirectional links is that it would make bidirectional links behave significantly differently from other links (where you can have many links), most executables would be impossible to add a bidirectional link for to anything but SYS:AppLocations, since there'd already be one pointing there (and if the user *were* to manage to add a link elsewhere, adding a link from SYS:AppLocations would mean you'd have to delete the users own link),

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
Anyway, I don't see the restriction of not being able to define more than 1 link per executable a serious one, both because links are rarely used for that (I do use links, but I never needed to create a link to an executable and I've never heard of anybody else doing it) and because the applocations system would make executables immediately accessible.

Quote:

and the restriction at the same time makes the AppDir: solution work fine.

Quote:

As far as I can see, what you are proposing could in that case be handled just by changing the mechanism used to notify the task that updates the AppDir settings - no need to touch any of the filesystems. I.e. if the mechanism was changed to be triggered by an explicit action by the user, and the system tracked renaming/moving files. It's probably a far simpler change than adding "proper" bidirectional links.

If so, be it
But then, we wouldn't have BLs, which could turn out to be useful for other things...

Last edited by saimo on 20-Jan-2010 at 03:10 PM.

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