avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <pe...@realityforge.org>
Subject Re: Cornerstone to Sandbox
Date Thu, 05 Jun 2003 03:02:45 GMT
On Thu, 5 Jun 2003 11:55 am, Noel J. Bergman wrote:
> I don't disagree with you, unfortunately, regarding the code quality in
> parts of Cornerstone.  Be that as it may, there are projects using it.  It
> would probably help if you, since you seem to have knowledge and opinion,
> put together a list of which components are good, which ones are crap, and
> why.  The default thread manager, for example, should be deprecated.  Leif
> Mortensen's replacement seems to be perfectly suitable.

Its the same list that I sent before and it spans excalibur and cornerstone. 
However some of it hinges on a fortress release (as ECM still uses it and we 
cant deprecate till ECM deprecated).

-- Deprecate Excalibur-Pool, Excalibur-MPool and replace with wrapper around 
Commons-Pool. Commons-Pool is far better documented, unit tested and 
maintained than anything in Avalon. A few odd naming conventions for methods 
but other than that I think it is superior to Avalon stuff in every way.
-- Deprecate Excalibur/Cornerstone Thread(Pool|Manager). Relies on 
Excalibur-Pool, not anywhere near enough unit testing documentation or 
maintanence. Replace with something based on Commons-Pool and higher quality. 
ThreadManager the concept should be deprecated and components should directly 
rely on ThreadPools. See http://spice.sourceforge.net/threadpool/index.html 
for an example of this. 
-- Deprecate SocketManager. Bad design - components should rely on 
SocketFactory or ServerSocketFactory objects directly. Unit test remaining 
code and document. Not actively maintained. See 
http://spice.sourceforge.net/netserve for the start of a revamp of this. 
-- Deprecate cornerstone channels. SOcket* can produce same results. Not 
actively maintained.
-- Deprecate Excalibur/Cornerstone DataSource as it can be replaced with 
wrappers around DBCP which seems to be high enough quality, better unit 
tested and actively maintained.
-- Deprecate MasterStore. Bad design - use a specific persistence mechanism or 
live with crappyness. Not actively maintained.
-- Rewrite Packet in same way sockets is rewritten. Unit test and document. 
Not actively maintained.
-- Remove cornerstone sax/dom as it is usually better just to use services 
directly. Not actively maintained.
-- Scheduler is mostly fine but needs someone to maintain it.

ie Scheduler is the only bit of code that is not done better elsewhere - and 
it is barely maintained. All the rest can easily put in sandbox or dumped.

> Meanwhile, the code having been released 

cornerstone has never been released and as such buyer beware. From the rules 
of Open Source 

"2. Don't take on a dependency on some other project unless it's either mature 
or you're willing to maintain it yourself. "

> With respect to a release process, Berin has one.  

I said maintainable release process which that is not. It does not engage the 
people who are actually willing to maintain releases. Consider 
excalibur-configuration - it is unlikely that will ever be maintained given 
no one uses except Merlin and only then a fraction of the package. It is a 
little better documented than the rest of stuff in Avalon and does have unit 
tests but it could hardly be considered mature and unlikely it will ever 
reach that level.


Peter Donald
Fools ignore complexity.  Pragmatists suffer it.
Some can avoid it.  Geniuses remove it.
-- Perlis's Programming Proverb #58, SIGPLAN Notices, Sept. 1982

To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

View raw message