Serge Knystautas wrote:
>
> Daniel Sadolevsky wrote:
> > Is I understand from the mailing list archives, the people working on
> > the framework are the same people that work on James, so if you don't care,
> > then nobody does :-(
>
> The *people* working on the framework are the same people that work on
> James, implying more than just me. I'm sure Pier and some of the other
> Java Apache members would care.
I wrote most of Avalon code so please ask me anything you feel wrong.
The Store is a block and you have just one Store in the framework. The
store provides to blocks as many Repositories as required. The
repository is the interface providing storing capabilities while the
Store Block only manage those repository. This is necessary to provide
private and public (eventually protected) repository (visible only from
the calling block or shared with all others) and to provide many
repository to the same block (under Avalon a block cannot access two
different implementation of the same interface es.Store).
There can be a Repository for incoming messages (SMTP spool), one for
each local mail user, one for password etc.
>
> 1) Blocks. IMHO there should be more of them, all on one level in the tree. I find
>it problematic that the spool and some other things are initialized inside
>SMTPServer. What if somebody comes up with some other message delivery block and
>still wants to use the spool? This can be solved by placing all the blocks on one
>level, referencing one block from another (in the configuration) by block name/id and
>initializing them in the topological sort order (using DFS or queue, does not
>matter). This, of course, would require for every block to provide a method that
>accepts configuration and returns enumeration of ids/names of all the blocks that
>should be initialized before it. The framework should be able to call this method
>before block initialization, so we can as well make it static.
> And, everything can be a block this way. Acceptors too - they would not require any
>special initialization treatment they do now. Thread pools too. For example, the
>simpliest configuratiuon would contain only one block as a thread pool, and all the
>other blocks that require thread spawning capabilities would reference this one by
>name/id (in the configuration, of course ...).
>
+-1...
Avalon is a set of rules and code and was designed to be as flexible as
possible (avoiding the flexibility syndrome) so that programmers could
fit their own software the best. This means I thought to James as
composed by N blocks but you can think of it composed by 10*N blocks.
This is my rule on what should be block and what not.
A block is a macro object witch can be shared between different servers,
with its own version independent from others blocks version.
Every block implement a specific public interface (Store Logger etc.)
and this make sense only this is a sharable interface that can be used
by different servers.
Inside a block you can create a microframework to manage the best your
mircoblocks like the spooler etc. in a recursive way. This because the
block level should be administered be the webmaster who can pay
attention to the new distributed, ultra fast Logger and update that
block under Avalon while the James spooler should be included in a
separate release of the SMTPServer.
The use of a recursive framework allow to well define layers each for
different people: block developing, server developing, multi server
platform etc.
There is no need to define a initialization order for block since, by
definition, each block is independent. A block CANNOT know when another
block was instantiated.
Acceptors are exactly as others blocks. The only reason they are
initialized first is for simplicity. You're right on this... The
important point is that acceptor MUST be Recontextualizable while block
CAN be.
+ 1 on Thread pools.
the reason I kept it inside Avalon and not as blocks was for security.
Probably this is quite useless but my idea was to let Avalon decide
threads priority etc., a sort of security manager inside Avalon but it
is probably useless at this point.
> > This is just an example, because I think that Store above
> > Repository is useless and SMTPServer should not talk directly
> > to the repositories, but through some "Spooler" block, that
> > should also handle the relay and final delivery, and should
> > reference in configuration to the repositories blocks that it
> > should use and to the "FinalMessageStore" block for final delivery.
> >
>> The idea behind the repositories (as I understand it), is that the
>> SMTPServer does talk directly to the repository, and another thread
>> watches that repository and handles relay and final delivery. I don't
>> know if abstracting a "Spooler" block really helps. What does that
>> accomplish that just accessing the repository directly
>> doesn't give you?
>
> In your next message, Serge, you write about specialized mail
> repositories, and this is exactly what I am talking about here. Still,
> there is a point of Store above Repository being useless. What's your
> opinion on that? Also you did not comment on the current block
> nesting/dependency.
The whole Avalon framework has, as mail goal code reusing so writing a
specialized mail store is IMNSHO a complete waste of time.
It's much more worth spending some time for writing a general enough
reusable repository.
The MessageSpool.java is exactly a specialized mail repository based on
standard Repository. For final delivery some similar class could be
needed.
A block like "MailStore" can handle POP3 and IMAP mailbox transparently
using defauld Repository.
Federico
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/>
Problems?: [EMAIL PROTECTED]
