Assign management

[SamuraiCrow]

An early issue I noticed, if it could be called that, is that ECX relied on some AmigaE modules. Or they were acceptable as the main assign, since it's been years I set ECX up. My setup had the EModules assigned to the 68K AmigaE modules with ECX added after that.

A secondary issue could be needing assigns and in this case multi assigns. I've thought for years assigns just complicate it for the user. But this is really because assigns (and application scripts) were never modularised like other components since OS2 when resources like DOS mounts were split and organised into files. I expected app scripts to be added to AmigaOS and especially OS4, as well as assign files, where scripts and assigns would be managed easily as files and an entire assign map would be as easy as dropping files in place. But for some reason this obvious feature to me wasn't thought about for the last 20 years of OS4 development even. Well that's off topic really. :-?

At the 1998 DevCon I proposed that the clumsy way that install scripts added and removed assigns to s:user-startup could be replaced by a preferences program and a more centralized database key-store. Hyperion didn't have transcripts to go by when they made OS4 so that got lost in the shuffle. Command path could have been handled by the same program and techniques, as proposed as well.

[Hypexed]

You were there before I possibly even thought if it. Also, unless I missed it, the only way scripts can do that is through the official installer. What I mean is an automated way the system manages it. Scripts doing it manually by modifying the file is unreliable.

It would actually be simple to deal with at first. Just like User-Startup was split off and the aforementioned DOS mount DOSDriver files. I would first propose some kind of drawer with app scripts ran on startup. These would have been script blocks usually added to User-Startup. But separated into their own files and more manageable.

Next would be an assign drawer such as DEVS:Assigns. This would contain files with assign lists. But could also contain links where the filename is the assign name and link points to drawer. Needing absolute paths could be a limitation. So, just like a program can have a local LIBS drawer for libraries, a local Assign list would also be supported. Where paths could be relative. A basic setup would let the assign be made relative to location, which would mean the parent drawer could be moved. If an assign reference is missing the system could search locally for any assign lists then search in system DEVS.

A possible downside is discrete files slowing it down against one file. But I think the benefits would outweigh any downsides. Hanging assigns would still be active, such as assigns active where the location is moved or removed, but would be more trackable. You can probably tell I've thought about this. :-)

I've tested a similar idea for using separate files on another project, the X1Boot manager I wrote for X1000 Linux, where I needed to manage different menu items and boot options. I chose to use folders for each menu item to avoid needing to manage it all from one file. This ended up working well. I should probably test my initial idea of splitting up User-Startup. This would help with adding existing apps to a new install.