AmiDock and application.library in AmigaOS 4

[downix]

AmiDock looks same as it always has, a pale shadow of similar docks found in other OS's, such as MacOS X, WM and OS/2.  An improvement over the existing AmiDock, but still nothing to write home to mama about.  (note, ad a general rule, I don't like Docks much to begin with, never have)

application.library, on the other hand, appears to be one of the worst kludges I've ever seen.  Rather than design a future-looking mechanism that operates behind the scenes, Amiga's fallen on the same approach that has belegered WOS applications for years.

[downix]

@teotwin

a system-wide xml based configuration system would be dog-slow compared to text or binary-based configuration systems.  The more apps access it, and thereby hit the interpreter, the slower the system runs.

[downix]

So why should this have any more impact on the system than your run-of-the-mill text preferences file, or a binary file?

If the XML handler was only dealing with just these configuration files, there would not be any performance issues beyond a nominal setup cost.

However, XML is also the core language for XHTML, the standard in web pages now.  It is likely that the XML parsing engine would be used for additional material, including but not limited to:  web page rendering, object file decoding, and document object viewing.  Now, suddenly, your application is waiting in cue to be handled by the parser.  I don't know about you, but long load times hurt a systems perceptions.

Note, this only works *if* the XML parser is shared as opposed to fixed-purpose.

[downix]

I used WOS as it is the best case that 90% of the other people out here understand.  The basic meaning is you're tying *every* application to a single library, and pray that no virus or trojan comes along and borks that up.  I have had WOS apps that fail to load because the WOS library got corrupted.  This kind of functionality should be handled by the kernel invisibly, which is actually easy to do.  (surprisingly, the mechanism for this was explained in the very document linked to)

While, yes, it will work, it remains to be an external, and thereby vulnerable, component to the system.  This results in all sorts of back doors and opportunities for errant code to do damage to the system.  Imagine a trojan that replaces application.library with a new one that runs normally, but also snoops your inputs in order to get such things as credit card information or personal data.  Extremely easy to do via this method.

Then there is the bigger problem:  You are running the system, by default, in emulation.  Only apps which use application.library are flagged as being native apps.  This is a horrid design, and creates more overhead in the architecture than is necessary.  This results in a complete slowdown due to an overload of latency-inducing checks and balances for the system.  "We don't have those checks and balances" is the only answer that would mean you aren't bogged down, but then you'd be unstable as all hell.  Talking you'd make AmigaOS 0.9 seem like a rock-solid UNIX contender.

[downix]

There is no system performance hit.

Would you like to take a bet on that, that XML based files render slower than ANSI or binary files?  Remember, I am quoting you here, stating that there is no performance loss whatsoever by using an XML based configuration system over ones closer to the hardware.

[downix]

application library only serves as a means to communicate with the dock. If a 68k program calls it, it would get the exact same treatment. We don't usually provide 68k interfaces to new services, so this pretty much excludes 68k programs from calling it.

See, this was not the impression I got from the overview.  application.library, from the overview, looked to be more akin to a userstate kernel than an interface for AmiDock.  Now it makes sence and does not look like some kind of mish-mash.  Thank you for explaining.