AmiDock and application.library in AmigaOS 4

[blubbe]

@Rouge

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.

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

And shouldnt a new standard be a better one ?

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.

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

[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 :-)

[blubbe]

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.

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

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

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.

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.

Okey, from what I understand, its not about
a super extended IFF, it could be done with IFF
"as is", only some useful "specifications on paper"
is needed, and practically no new code needed.
But, whatever, its decided already  :-(

[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.

[nOw2]

(I have absolutely no idea how this web interfaces quotes stuff, so you'll have to use some imagination

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

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.

No. There is no standard on the Amiga. Some programs store their settings in S:, others in ENV:, and others in the application's

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.

Your highly-acclaimed commodities 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.

*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),

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

It's on disk 83.

and is now an OS component. Application.library is as much an OS component as e.g. datatypes.

I don't deny this and didn't suggest it would not be the case. Originally I only stated my disappointment that duplicated functionally appears to be included in the OS. I can't influence this at all, and god knows I'd rather let competent people do the hard work for me anyway.

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

[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"

[zee4]

@Valan,

I still think a modern variation of the WB1.3 would be a great place to start.

Yes! I'd love to see someone do a re-interpretation of the 1.2-1.3 interface. If OS4 is as skinable as the screen-shots indicate, this shouldn't be a problem for someone to do.

Zoltan

[zee4]

"a system-wide xml based configuration system would be dog-slow compared to text or binary-based configuration systems."

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

@Rogue,

Good point. I could see the advantages off a binary-based preference system in 1985, but I think the advantage of having a human-readable prefs file trumps the (tiny) performance hit from parsing an XML file.

Zoltan

[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.

[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.

[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.

[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.