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.

-- 
Cheers,

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


Mime
View raw message