[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MiNT] WCOWORK vs WINDOM for components

Quoting Odd Skancke <ozk@atari.org>:


powerful and flexible event system.  The only thing I want to see from a
component system, plugin system, or dynamic library system is the ability for MiNT itself to load plugins and export a hierarchal tree (maybe a filesystem) of available plugins (dynamically loaded by the kernel and MP safe, not user). For the equivalent of dynamically linked libs, I like Howard Chu's suggestion 
of relinkable static libs - should be nice and fast for gemlib, mintlib,
windom, and things of that sort.



 Most of the things above does not belong in the AES kernel at all.
I never said they should be, and that was kinda my point. Only the parts that I 
left of my original message where I talk about the kernel are the parts that I
wanted in the kernel - that was the point of starting with this statement.
Subwindows was an in-kernel way of doing things in multiple processes that would 
be more appropriate to do with a component system.  Now, I know my plans for
loadable components, and I know other people are working on similar things.
Hopefully, we can make these systems interact with each other and be
compatible, but the AES won't have anything to do with it.


 I mention WCOWORK mode and what benefits it may have in the future, and
all of the sudden there are so many balls in the air that one cant
Well, you continue to bring up all the wonderful features that WCOWORK mode will 
bring us, and not everyone agrees that these new features are necessary or
beneficial.   However, no one is disagreeing that the benefits of using just
WORKing coordinates are really great.  I don't disagree on that point.  WORK
coordinates good.

Now ... you no longer have to bring up any discussion about the benefits of
WCOWORK. Strange discussions on applications composed of other applications in 
subwindows and all this other stuff can be left out.  I don't need to hear
arguments about the benefits because we agree on that point.

The problem is the implementation.  Thats all anyone has ever had a problem
with, and you keep coming back saying that we don't understand the benefits
this new mode will have.  We do.  We agree.  Its how its done that concerns
people.  Address just this one issue, and we might get somewhere!


breathe. I read what your plans are, but I have no idea how you want to
implement things at all. You seem to mix lib functionality with what
should be in the AES kernel. All this talk makes me feel unadeqate, I


NO!  I'm saying that what you want to do with subwindows is a just a subset of
the functionality you can get with a proper component system.   The component
system won't require any changes to the AES at all, is perfectly fine with VM
and MP, and efficient. You accuse me of mixing lib functionality with AES and 
I'm saying that what you want to do should be done by a plugin system within a
single process and a single window, all in userspace with libraries.  No AES
changes.  I'm not the one adding AES complexity and making odd AES changes.

Windom has a scheme in mind that is likely very different from mine - and
hopefully we'll find a way to not duplicate efforts and make incompatible
components, but I'm not too worried about it since my system can wrap any C
functions pretty easily, and if it can't, I need to work on it, so I should be
able to work with Windom components just fine.


dont understand half of it (apparently noone else either since noone
else uses these ideas). I therefore kindly ask you to take over XaAES
development, I've had enough.
Hmm .. you were one of those kids where if you couldn't be captain of the team, you took your ball and went home huh? Its your way, or you won't play with us. 

-- Evan