james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: What do we need to release 2.1?
Date Sat, 17 Aug 2002 01:17:27 GMT


Noel J. Bergman wrote:

>>1) IMAP - I think this one is going to be on most people's list.
>>    
>>
>
>It may be on everyone's list, but I would not trust it for the release.  It
>isn't ready, and I would not want to hold up the release.
>
>We can always put out a post-2.1 beta with IMAP included, but I would not
>hold up a stable SMTP/POP release waiting on IMAP.
>  
>

My impression what I look at James from the Merlin perspective is that 
James is actualy made up of a number of reusable components - and DNS 
sever, SMTP server, mail reposirtory, NNTP server, etc.  IMAP is just 
another component.  The point I'm getting at is that it could be usefull 
to look at James in terms of its component parts - start qualifying 
these in terms of stability, version management, etc.

One of the benefits that falls out of this is a mre transparent story 
concerning the management of integration of email related services into 
other environments.  For example, I want to be able to totally replace 
the user storage system with my own internal framework - a clear 
breakout of components, dependecies, status, etc. - make that an easier 
proposition to deal with.

>  
>
>>1) TLS Support for POP3 - This is really a rather simple piece
>>    
>>
>
>If it is simple, fine.  Bug fix == good, new features == next go-round.
>
>  
>
>>Internal Documentation
>>    
>>
>
>Absolutely necessary.  But NOT to hold up the 2.1 release.  
>

At least get the javadoc complete.   My personal preference would be to 
slow down a release ifg that was necessary to get documentation in place 
- but at the same time I know I probably won't be writting much about 
James internals - so take this comment with a pinch of salt (on the 
other hand, when we sort out James in Merlin I'll be happy to provide 
the doc for that).

>We can continue
>to upgrade the web site with new documentation, and any serious developer
>should be working from the CVS.
>  
>

Agreed.

>  
>
>>External Documentation
>>    
>>
>
>Again, absolutely necessary.  But NOT to hold up the release.
>
>  
>
>>1) Migrate all Composable to Serviceable
>>    
>>
>
>Makes me a bit nervous, as it seems to be a significant change, but I
>haven't had time to look at the code revisions, and you have.  What gains do
>we get other from it other than cleaner code and the fact that Andrei also
>removed the dependency on TimeScheduler?  What effect on defects, stability,
>performance, footprint?
>  
>

Nothing to be nervouse about - I have a business platform here (company 
product with around 40 signaficant compoents) and a lot biggger than 
James - migration from ComponentManager to ServiceManager to about 2 
days.  Basically the ONLY difference between the service package and the 
componet package is that you can throw away the Component interface 
(which is empty anyway).  This has a big impact because you are now 
no-longer locked into the Avalon framework - your components can be as a 
simple as a java.lang.Object with an zero argument constuctor - 
integration of non-Avalon components becomes possible - James becomes 
more usable outside of the Avalon world.

Go for it - its a good thing to do.

Cheers, Steve.


>  
>
>>3) Change code so that it doesn't use the TimeScheduler
>>    
>>
>
>Either that (e.g., a resetable watchdog thread per service thread), or write
>a TimeScheduler class that is more space efficient for our needs.  Moot
>point if #1 (previous paragraph) gets done, since it is included in that set
>of changes.
>
>Bottom line is simply that 2.1 is advanced far enough that I think we should
>be just focusing on making sure that it is stable.  Anything that doesn't
>contribute directly to stability can be deferred to post-2.1, in my opinion.
>
>As soon as we are done with 2.1, I think it is a high priority to add
>attributes to mail and user objects (and repositories).  A lot of work is
>being hindered by their lack.
>
>	--- Noel
>
>
>--
>To unsubscribe, e-mail:   <mailto:james-dev-unsubscribe@jakarta.apache.org>
>For additional commands, e-mail: <mailto:james-dev-help@jakarta.apache.org>
>
>  
>

-- 

Stephen J. McConnell

OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net




--
To unsubscribe, e-mail:   <mailto:james-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:james-dev-help@jakarta.apache.org>


Mime
View raw message