Scott Sanders wrote:
So then you start moving it over. In commons everything is
broken out
component-wise, but this is nothing new. Let's start
talking about how
to go forward with whatever you/we feel should be in the
commons. I see
commons as a bunch of components, but I tend to NOT see a
framework in
commons.
So let's get all Excalibur's and Avalon's utility code into commons,
then Excalibur still uses it, and commons doesn't have to rewrite
(although rewriting seems to be the jakarta way, IMHO). Everybody
should win. Right?
Theorhetically.
Now Avalon utilities include a pooling implementation that is
nothing like
the Pool package in Commons. Should the new pooling package
be moved in
with that? And then what about the synchronization
primitives? Do we know
where they would go?
What makes the Excalibur pool different/better? We start talking about
it to see what to do:
- Can we condense/refactor to just one?
- Do we need both?
- Is one better/more useful than the other?
The pooling ideas are different. I am beginning to experiment with
managed pools that perform sizing information in a separate thread.
The experimentation happens in Excalibur's Scratchpad, not in the
released jar.
There are many things to discuss.
We just need to start talking about it :)
All of this is just an email thread away ;-)
Ok, let me talk with the Avalon committers, to see about doing this.
IMHO the synch primitives would go with the threading proposal in the
sandbox. Do your primitives look like these? How are they different?
Actually, what is in the Threading project is mostly queue classes...
something that I am working on and have a very cool implementation of.
(I.e. how about transactional enqueuing, etc.).
There is a Semaphore and Mutex object in the commons project, but no
DijkstraSemaphore (we have both), ReadWriteLock, ThreadBarrier, or
Sync interface.
The Excalibur event package has the queue classes and implementations.
The Queues have been tested threadsafe and can perform a complete enqueue/
dequeue pair in a few nanoseconds (based on average of 11 million
enqueue/dequeue ops). Further, the Queues have transactional enqueuing
capabilities that work like this:
PreparedEnqueue stack = queue.prepareEnqueue( elements ); // elements is an
array
// of QueueElement
objects
if ( condition == ok )
{
stack.commit();
}
else
{
stack.abort();
}
There is more, but that is one point of distinction
I am actually excited about commons and Avalon/Excalibur working more
closely to each other. Sam came in with Gump and managed to get the
APIs to stabilize, now we need another level of cooperation. I think
that this can make it happen.
I would like to see this happen, but am feeling this out step by step.
As an aside, I have now read the "Developing with Avalon" paper and I
must say that is the best description of a framework that I have ever
read. Excellent work!
Thank you. All I did was summarize a year and a half of email conversations...
Not that easy, but in the long run, it helped out many people including
my company :)
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
