[Pkg-ace-devel] Re: [ace-users] Bug #1854: Reactor Implementations

[Raphael Bossek]

--=.kGtA'3ilRbIi)K
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

> That is so cool! Would you be interested in pushing your patches
> upstream to us?
Of course! I'm in conversation with the Debian GNU/Linux ACE+TAO
maintainers to get the things right. I hope things works fine.

> > I would like to enable all reactor implementations at build time. 
> Why? I don't understand this.
I think for a Linux distribution e.g. Debian where the developer have
the choice selecting precompiled packages. For some people it takes 13h
get ACE+TAO compiled. Debian will offer precompiled packages with all
reactors and most of the other features already enabled. Only few people
have to recompile then.

> Seems like a good idea. But it has other implications, i.e., breaking
> our existing philosophy, which is to offer a core and add other
> features based on needs.
The core will remain the same. The addons will remain the same. You have
to select the addons (as libraries) at link time of your application.

It is important to have _one_ variant of ACE+TAO+CIAO and different
application linked against them. The application's developer need a pool
of precompiled libraries which work together and choose what he needs
for his application. It would be a vast of time and space building and
installing ACE+TAO+CIAO for each application from scratch.
One team of Debian maintainer works on open issues beginners or reckless
ACE users do not consider or know.

> I am not sure whether there is a policy or not. But we as developers
> know for sure that TAO will not work well with say Tk or Qt reactor.
> When I say "will not work well", it includes the following
> . All the capabilities of TAO, like nested upcalls, synchronous
>   upcalls, etc.
> . Haven't been stress tested even a bit
> Due to the above, I am always suspicious of the above reactor's 
> capabilities.
If it is as it is the Debian version of ACE+TAO+CIAO will disable the
support of Tk and Qt reactors for TAO. This will guard reckless and
unexpierent users from trouble.

> Our policy has been to provide the minimum subset with which one can 
> write meaningful applications. Everything else is optional.
It will be for Debian too.

> If you can explain us why this is wrong or what we have got wrong, it
> would be awesome!
You are not wrong and you have my complete comprehension. What I intent
do to is to do the same but with the possibility to devide the addons in
seperate libraries if enabled. It is not a modification of today's philosophy. Is only an another way handling addons with ACE+TAO+CIAO. If
addon functionality is enabled a new (shared) library is created for it.
There won't be one big library with many features in. You will get
a bunch of libraries for all the features you enabled.

The advantage is not where only one developer/application exists. Hmm,
it's even a disadvantage for a one person's project (you have to spend
more time handling with libraries).
But the advantage is where multiple ACE+TAO+CIAO application from
different sources have to work in the same environment (e.g. same Linux
distribution). Any application have different requirements on the
functionality of ACE+TAO+CIAO. One application more the other less. E.g.
for a project where I intent to use ACE is low memory footprint and less
dependencies on libraries more important then features. I can not
accept an dependency on any graphical library (e.g. X11 or Qt).

But I do not like to block other application which maybe need them. If
someone select the dependency on Qt or X11 I have to respect this.
A version of ACE+TAO+CIAO where features are part of (shared) libraries
will offer the flexibility of choice. Every application can coexist in
one environment without bothering each other. (Maybe I have to use this
application some day. Who knows.)

--
Raphael Bossek
--=.kGtA'3ilRbIi)K
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)

iD8DBQFBWHarN2lBq4Nesv8RAvOPAJ0T+y2mZbIIt6BtGow8d1oaqlFfLwCfZMIy
SA6iYE0hxWsPrUpOSD86440=
=QaFg
-----END PGP SIGNATURE-----

--=.kGtA'3ilRbIi)K--