AmiDock and application.library in AmigaOS 4

[Rogue]

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.

Explain that, please. The prefs are read when the application starts, and written when the application wants to save it (which is quite rare).

Why should that have any impact on performance? That would only happen if you would re-parse the XML file every time the application wants to access on of its prefs items, but that would be braindead. Application.library caches the file in parsed format in memory.

And if you want to guard against external modifications of the XML file, you set up a DOS file notification and re-parse only if there has been an external access.

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

[Rogue]

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.

Are you sure you understood how this system works? I can't seem to find how this relates to WOS in any aspect.

[Rogue]

Application library appears to clone functionallity in commodities.

No. Commodities is a way to install custom input handlers into the input.device's even stream.  Application.library is something different.

Is iffparse.library and ENV not standard in AmigaOS?

No. There is no standard on the Amiga. Some programs store their settings in S:, others in ENV:, and others in the application's own directory.  To the best of my knowledge, only IPrefs stores its settings as IFF in ENV: Others do whatever they feel like. Application.library is meant to provide a standarized way to do this.

Applications.library doesn't seem to have been well thought out at all; certainly it seems more like a 3rd party tool than an OS component.

Your highly-acclaimed commodities library *did* start out as a 3rd pary tool (on a fish-disk, I think somewhere around 50 or so, if you know what that is), and is now an OS component. Application.library is as much an OS component as e.g. datatypes.

[Rogue]

So you mean, introducing yet another way to do it,
is setting a standard ??

No, not "yet another way". The way it should officially be handled. We're trying to outline a way that future applications should handle it, to get people away from the "I store my config files whereever I like" kind of attitude.

And shouldnt a new standard be a better one ?

What's so hot about the old way of storing your prefs files wherever you like?

How about taking some time to read up on that
"old" and "outdated" IFF that already exists.

Not saying its the best there is, but a good starting point.

Did that, and decided that we have a better solution. I am not going into this brainless discussion again that I just left on ANN. Like it or not, XML is it. I don't see any reason to pursue your or anyone's fictious super-extended IFF when there is an ad-hoc solution that draws from industry standards.

And btw.. Here is all the .prefs files in my ENV:Sys
(IFF)

ahi.prefs font.prefs
fullpalette.prefs input.prefs
locale.prefs midi.prefs
palette.prefs printer.prefs
printergfx.prefs screenmode.prefs
wbconfig.prefs WBPattern.prefs

 If that was a try to prove your point, it was rather pointless.  Most of the files are system preferences. Fullpalette and ahi aren't, so they don't have any point in residing in env:sys in the first place. So if at all, this serves as a good example why things should be changed in the first place.

OTOH, I am not going to list the contents of my S: drawer now, or the myriads of files that are in env:  If you still insist that this is the way to go, suit yourself :-)

[Rogue]

Ok, like the move from S: to ENV: you mean ?

It doesn't really matter where stuff is saved, the point is consistency.

Well, S: is not a good place, it wasnt even intended for that either. ENV: is good for smaller files, especially single "variables". PROGDIR: is good too,
for larger files.

I think that every application which is a bit larger and has its own directory on disk should also store its prefs file there. This way, you can make a backup and restore the backup later without worrying about "auxilary files" (or the stuff that windows refers to as "shared system files"). An Application should be a neat package without spreading its files all over the place.

practically no new code needed

There are other implications. If you want to, check the thread on ANN. An ascii based file format makes the most sence, mostly since the prefs files are usually small.

[Rogue]

Commodities Exchange appears to offer some of the functionality offered through Amidock using application.library, with the infrastructure in place to do much more. At least, *I've* been using it in this way for years. I can't speak for others.

The same functionalty is more or less offered by both "More" and "Multiview" (viewing text). That doesn't mean that the any of these should be gotten rid off, since Multiview will not work from the initial boot.

Commodities does *not* offer an application the possibility to display status information in an icon, add a popup menu, or save its preferences in any way.

I believe that even with application.library it would be possible to save settings in S: (unless S: is replaced with /etc/rc/ or something). Just because people don't follow The Ways Things Are Done (TWTAD) doesn't mean that TWTAD isn't a defined standard.

Of course it is possible. However, you are wrong if you claim that there is a standard. Application library offers an obvious way. Of course you can't force people to use it, but then, we cannot forbid  people to call Open/Read/Write/Close. So I don't see your point against application.library.

Do not put words into my mouth. I am perfectly capable of speaking for myself without anyone else voicing their opinions in my name.

Huh? Wasn't it you that brought up the commodities example? It was you, IIRC, who said that application.library duplicates functionatliy.

Don't be rude. It doesn't help to win arguments and influence people.

Rude? You *are* aware that the fish-series has been stopped *quite* some time ago. Of course you are free to interpret this as rudeness, but I am quite sure that a lot of people here never heard of the fish disk series. If that offended you, I apologize, It was not intended as such.

Originally I only stated my disappointment that duplicated functionally appears to be included in the OS.

Like I said, some duplicate functionality is already there, but commodities is something completely different (I found your comment about not being well-though about rather rude, but let's not dwell on this).

So, I'd prefer an explanation of the reasoning behind it rather than what I've read so far!

People will probably not believe me when I say that we have given a lot of thought about things (at least not from the comments I always read). We don't decide on this or another feature without lengthy (and sometimes very heated) discussion.

The reasoning is there, but I don't feel the urge to explain it all, since we are adding quite a number of features, and the usual reply to this specific feature is "IFF is better than XML"

[Rogue]

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

That would only be the case if there is a single process that decodes XML. The application.library only handles preferences, and the application using it doesn't even know it's XML. Generic XML services will be available in the form of a shared library, that can be used like e.g. iffparse.library. There is no system performance hit.

[Rogue]

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

A much better target for attacks of these kinds would be DOS, Intuition, Graphics, or what have you. Granted, they are rom-resident, but it is so easy to patch a rom resident library, or replace the SetPatch program. Or the LoadWB program.

This kind of functionality should be handled by the kernel invisibly, which is actually easy to do

It depends on what you define as an "Application". I definitely don't want every "dir" or "list" to pop up an icon somewhere. OTOH if I start an editor, this is when I want its icon to appear in the Dock. There is no way you can find this out, and it is much better to leave this to an application author.

While, yes, it will work, it remains to be an external, and thereby vulnerable, component to the system.

AmigaOS is no secure system. It will need to go a long way to actually become one. Like I mentioned, SetPatch would be my primary goal for a trojan attack, or LoadWB, BindDrivers, Or a monitor. Everything that is executed on all system at startup.

You are running the system, by default, in emulation. Only apps which use application.library are flagged as being native apps

No, that is wrong. The system is running mostly native. Only a few components are going to stick in emulation. Most of all, no application is flagged as being anything, because there is no distinction between native and emulated applications. This is the exact reason why we didn't go for a sandbox approach but instead treat 68k tasks exactly like PowerPC-Native tasks.

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.

[Rogue]

Would you like to take a bet on that, that XML based files render slower than ANSI or binary files?

Either I am missing a word here, or that doesn't make sense. What does "render" speed have to do with this?

What I meant was that it doesn't matter how many applications use an XML parser simultaneously. There is no such thing as an "XML parser server" that needs to serialize the parsing (that is how I understood your first comment). The XML parsing is a normal library, and will work in a multitasking context like a custom parser for a custom prefs format (or IFFParse for the matter).

Also, the overhead of parsing an XML file vs. parsing any ASCII based file is so small that it doesn't matter.  Of course a binary file formwat would be slightly faster, but the difference will barely be noticable.

So yes, XML is slower than binary, and might be slower than another ASCII based format (although that is debatable and depends on the format of this thing).  I don't see however how the fact that a web browser might use an XML parser would have any impact on the startup speed of an application.