Re: [MiNT] WCOWORK vs WINDOM for components

[Odd Skancke <ozk@atari.org>]

lør, 23,.07.2005 kl. 20.41 +0200, skrev arnaud.bercegeay@free.fr:
> Hello,
> 
> I'm offline most of the time in july and august, so it's very hard for me to
> read all the posts, and impossible to reply.
> 
> BTW, i read so many wrong statements that i'd like to reply to some key points.
> 
> > I trust Ozk 100% to have good reasons for not wanting to play the game as
> > you are suggesting. When it comes to implementations in FreeMiNT and its
> > components, I do put my faith in Frank Naumann and Odd Skancke, since they
> > (to a very, very, very large extent) are the ones who are making it all
> > happen.
> 
> Yes, they are the main developpers of freemint+xaaes, and for sure they know
> very well their job, but do you want an OS without applications ??? They are
> not the main developpers for applications, and for new xaaes features described
> in this ML, a feedback and return of experience from developpers is needed
> (IMHO) because this new xaaes feature is something that windom developpers
> already experience for years.

 I didnt know that. What new XaAES feature do you mean?

> 
> First, i'd like to remember what is an "AES application". Most modern
> applications uses libraries. Let's say windom and gemlib for example.
> 
> Then, the "AES application" (the file.app you double-clic on to launch) is
> a package of them :
> 
> file.app = (code written by the developper) + (windom.lib) + (gemlib.lib)
> 
> If one wants to use a "wout" window, then the executable will be
> 
> file.app = (code written by the developper) + (wout.lib) + (windom.lib) +
> (gemlib.lib)
> 
> And file.app runs over the AES (and GEMDOS and VDI...)
> 
> Now, if one or several of these lib is provided as a dynamic library, then the
> "AES application" will be (file.app) + (windom.ldg) + (wout.ldg) for example (3
> files).
> 
> In the following, i'll speak about "well known" static libraries only... but for
> sure, this applies too for dynamics libraries, but it's not the subject.
> 
> ok. Now let's talk about current evolution of xaaes. The "futur" for xaaes is to
> introduce some mechanism (in xaaes) so that an application can have a framed
> window with QED in one frame, and HW in the other (for example)... For that
> purpose, a lot of things still have to be define (how data of one frame may be
> exchange with data of the second frame because they are 2 different processes,
> for example).

 True.

> 
> Well... if you had have a look at windom, then you saw that windom already
> propose a "frame" API that answers all your needs. With the windom "frame"
> feature, you can develop an application that open a framed window, with QED in
> one frame and HW in the other. The mechanism is already here. The "long road"
> target you plan for xaaes is something that already exist for years thanks to
> windom. Developpers just have to use it !

 I didnt know windom could do OS housekeeping needed to make this work
smooth. However, the IPW idea was not the real discussion, WCOWORK was.
IPW was just an idea, altho I thought a good one.

> 
> In other words, what you tried to introduced in xaaes is a feature that already
> exist for years in windom. If you still want to introduce this in xaaes, then a
> good idea is to understand how windom works, and benefit of the experience of
> windom (read on please)...
> 
> We (windom developpers) find out that "framed" window in windom (wich is very
> similar to what you have described in this ML) was not flexible and powerfull
> enought, and after hours of discussion, thinking, argmentations, we conclude
> that we missed a COMPONENT mechanism, and we spend a lot of time to define what
> a COMPONENT should be and what it should not be. At the moment, we are about to
> deprecated the "frame" feature because a COMPONENT is much more simple to use
> and develop, and it's much more powerful and flexible, only advantages !

 I can think of several reasons why this conclusion was made. One being
the fact that windom is a library, not part of the OS.

> 
> What's Evan has described (and what you labeled as too ambitious for a long term
> purpose for xaaes IIRC) is just what windom developpers can experiment at the
> moment by using CVS version of windom (i'm not 100% ok with the implementation
> proposed by Evan, but the main idea is good IMHO).
> 
> To sum-up, i'm sure WCOWORK is a very bad idea. If you still not agree (after
> having a look at windom), then go ahead, and in 2-3 years when applications
> will start to really benefit from this feature, you'll see that you missed a
> "real" COMPONENT feature and then you'll deprecated WCOWORK, and later, the new
> component feature of xaaes will allow developpers to do exactly what windom
> developpers can experiment NOW on every AES !  What a revolution !

 I have found out that there is no room for any further development of
XaAES. Reason I say this is that every new development goes on outside
the AES kernel, in the form of libs, etc. And when new features like
WCOWORK cannot even see the light of day because "windom already have
it", I no longer see the point. New features seems to belong in
libraries. I dont agree, but I have to give in because if the last
remaining scene wont use new feature, I dont wont to spend time
developing them. The fun is gone.

 XaAES development is therefore not for me anymore as it is quite up to
other AES's by now. All new development for our platform seems to be
centered around libraries. It is clrearly stated above that new features
will make XaAES 'a OS without applications', because the only library
worth mentioning wont be supporting it. 

 Because of these reasons, because I had goals beyond making XaAES just
another AES, I resign from XaAES development.

> 
> Last note: the COMPONENT feature is still experimental in windom, we need to
> test it more before stabilizing the API of COMPONENTs, but the first try of the
> COMPONENT feature is here, and AFAIK it works.

 Good.


 Odd Skancke