Open Amiga - Defining the Standards

[Rogue]

Wayne wrote:
They (Amiga Inc, Hyperion, or Eyetech) will, unless I am mistaken (which is possible) see any attempts to design an Open Amiga architecture as a threat to their existence. After all, they're not getting paid for it, right?

It's nice that you at least acknowledge the possibility that you are wrong. Plainly, I find it rather disgusting to talk about "Zealots" in such a colored, unfounded, and highly zealous statement.

I don't see open standards as a thread to our existence (in fact I was attacked on this very site and on ANN for promoting the adoption of XML as an open standard). However, I don't see much chance for an open Amiga standard, out of purely technical reasons - the choice of MUI on MorphOS and Reaction on AmigaOS already means that there is a gap. Saying people should use MUI is not a solution, since OS 4 doesn't endorce it.

Of course you could argue that we chose Reaction out of purely zealous reasons, which wouldn't actually surpise me. But of course, I could be wrong.

[Rogue]

Thanks for taking the time out to give us your opinions on OpenAmiga.

I didn't give an opinion about it. I like the idea, but I think it is not going to work unless you settle for the smallest common featureset. This means that you neiter use AROS nor MorphOS nor AmigaOS to the extend that it could be used.

Sure, for some things it is going to work, but the Reaction <->MUI example is already a case where you run into trouble. Sure you could argue to use MUI in both cases since it is available for both,  but what if certain components are only available for MorphOS (AFAIK the MorphOS developers don't need to merge with the general code anymore, meaning that OS 4 has no access to their modifications).

The feature list on the web site indicates the "smallest common subset" thing already.  

(I wonder though why it needs to specify the executable format; with a certain certainity, a MorphOS ELF file will not run on AmigaOS, and an AmigaOS ELF file will not run on AROS. )

As you have said, these standards don't pose any threat to anyone.

No, I never claimed otherwise (It was Wayne that did claim Hyperion would). As I stated before, I am all for open standards - another reason why we have XML services integrated into AmigaOS.  Of course I don't speak on behalf of Amiga or Hyperion officially.

I wish those behind the effort best of luck. When AmigaOS 4 is done, all documentation for it will be available, and people will be free to use it to produce software for AmigaOS 4. I don't have a problem with the same software running under MorphOS or AROS (in fact while Hyperion never officially supported anything but AmigaOS, we did likewise not build anything into our programs to prevent them from running under MorphOS or Amithlon).

However, please also understand that we're not going to hold back with implementing new API's and system components for compatibility's sake. If we think that it will bring the platform forward, we'll go ahead and do it,

[Rogue]

Wayne wrote:
I find it very interesting to get your input and hope that you speak for both Amiga Inc and Hyperion in your acceptance of the effort.

I can't speak for either Hyperion nor Amiga, however, I think I can say that the production of software is in our own interest - after all we don't do an OS just for the OS' sake.

... by Amiga Inc trying to kill it as they have done with other community efforts in the past,

I think that AROS is still alive...

I don't view this effort as wanting to impose any petty proprietary packages such as MUI or Reaction.

The openamiga.tk homepage does exactly this: It lists MUI as a requirement.

But that is exactly one of the problems you face. If you look at the Linux world, many of the projects there that would be an easy port to the Amiga fail to be such an easy port because of the GUI system.

If you want to define an open amiga platform, you would need to start at a higher level, otherwise you do exactly this - select a few proprietary packages and declare them standard.

By all means, if you want to have an open standard, you have to abstract from the packages you have. You need to define an API layer that can be mapped to the specific API's of the systems you are targeting. The only item from the list that fits this is SDL. Anything else is choosing one package and making it standard.

In my opinion, what needs to be done is define an abstract API for handling user interfaces, audio, kernel services and file services, and implement this on the respective platforms. Anything else, and you'll drive yourself into a dead end.

f anything, I would see them developing a wholly independent solution where necessary.

Seems we fully agree here  :-)

[Rogue]

It really was as simple as that... no politics, no jibes, no conspiricy... just simple logic.

Didn't want to imply anything else. Like I said, I doubt that it is possible to define a common standard on the component level you chose. These API's are already going separate ways, and the gap is going to widen. For a common platform, you need to aim at a higher level. SDL fits into the picture, because it is developed indenpendent of the OS it is ported to. The same needs to be done for other parts.

Only when you control the API can you ensure interoperability. This is why a program like GIMP can run on Windows and linux - because it is based on glib and gtk.