Federico Barbieri wrote:
>
> 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.
I apologise for the tone I seemed to take: "nobody cares", etc. - I did
not mean to sound like this ...
> 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.
>
As I understand from the above, Store is required only because some blocks
require temporary (private) stores, right? Now, these private repositories
are generated on-the-fly whenever blocks request them. But what if I want
to configure block A to use one implementation of private stores and
B to use another implementation? Logical way to do it would configure
A to use Store block C and B to use Store block D. Here "goes"
"only one implementation".
And I think that separation of stores that handle private repositories
and stores that handle public ones would be nice. Afer all, the
configuration
is radically different for both ...
> > 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.
>
I understand that you use interface (or interface name as I see in the code)
as a key to access the block. I see 2 problems here:
1) It limits block to one interface that it can implement and expose.
Flexibility--.
2) It allows only one implementation per interface per configuration. Same
about flexibility. Look at what I wrote about stores above in this message
for example.
As for your definition of block, what is "server" if not "block", and can
you explain more about "independent versions"?
> 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.
>
Again, the spool should not "belong" to SMTPServer alone, because there
can be another message transport, besides SMTP, that needs to reference
the spool.
And the logger - why it is not possible to configure different blocks to
use different loggers? For example, I would like to debug IMAP server alone
by pointing it to separate logger with different loglevel and destination
set.
> The use of a recursive framework allow to well define layers each for
> different people: block developing, server developing, multi server
> platform etc.
>
"To iterate is human, to recurse is devine" :-)
+1 on your intentions. -1 on the implementation: it could have been "more"
recursive. Simple "recursiveness" smoketest would be for SMTPServer block
to extend Avalon in order to include MessageSpool block, but it does not
in reality and I doubt if it possible. Some thoughts about how to "enforce"
the recursiveness?
> 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.
>
I am starting to understand your line of thought ... Can we in reality
allow only independent blocks? [Continued below]
> 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.
>
Another thing that makes them different is that they ARE dependant on other
blocks. Which in your model forces them to be treated specially. This also
prevents SpoolManager from being a block because it is dependant on
MessageSpool.
And why can't we force blocks to be Recontextualizable? After all, we do
want the possibility to configure every block at runtime, don't we?
> + 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.
>
If you are talking about regular Java thread priority, it can be a
configuration
parameter of a ThreadPool, and if you are talking about placing Stoppables
in some kind of priority queue when the pool is busy, there is no point
to do it if you can have several differently configured pools.
> 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.
>
True.
Daniel
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/>
Problems?: [EMAIL PROTECTED]
