Daniel Sadolevsky wrote:
>
> 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 ...
>
No problem. I was not offended.
> > 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 ...
I do not agree on this. From my point of view is logically wrong to use
two different implementation of the same interface inside Avalon. You
can have two different instances of the same block with different
configuration or for security reason but not different implementations.
What is the meaning of having one instance of the Logger under
org.apache.omero and another one under com.mycom.avalon.logger?
You can define in conf to use one Store for your transactional
application and another instance for all other servers for security
reason but that's all you can need (IMHO).
So a block can ask to avalon for an implementation of a specific
interface and will be provided with a specific implementation depending
on confs. This means a block can have just one instance of an interface
implementation. So if you need to store mails and user data in different
places you'll need a two level interface like the Store-Repository is.
Store define the block will Repository is the working interface.
A block can have a private repository for its own stuff and ask for a
sharable one. Any other block using the same Store instance will be able
to share that public repository.
>
> > > 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--.
Right. That was a choice not an accident. IMO if you NEED your block to
expose more than one interface you've done something wrong in your code
design. Since interface define logical service it does not make any
sense to me that two different incorrelated services are performed by
the same block. You MUST split your code. This is a programming pattern
that IMO should help good coding.
> 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.
If current Logger implementation is not enought for you you MUST NOT
write your own implementation, use it, and let all others blocks use the
old one! You MUST patch and upgrade current implementation to 1.1. If
you cannot patch current implementation you'll define a new interface
"ExtendedLogger" and if it worth everybody will switch.
> As for your definition of block, what is "server" if not "block", and can
> you explain more about "independent versions"?
A block provide a simple service. Logger, Store, ServletEngine,
XMLParser etc. are blocks example. A server is made of a set of blocks:
an SMTP protocol handler, a logger, a store, a mail server together make
a SMTP server. An SMTP server, a POP server etc. make James which is
another server.
Now James do not have a version. That's becouse I can use Store version
1.5, SMTPhandler 1.2 etc. and that's up to the administrator.
A block is a group of classes which perform a service. It's a black box.
Everithing I know about a block is its interface.
>
> > 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.
Agree on this. I'd like to provide others blocks with the ability to
send mails not using SMTP but an internal interface. I was thinking
about defining an SMTPHandler and a MailServer. The SMTPHandler parses
the protocol and call the MailServer with "handle this incoming mail
(mail)" or something like.
The point is that since blocks are administered by the administrator,
the less they are the easier it's his work. So you can split a block in
two only if this can be of some use to others block.
> 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.
You can do it. Just define in confs a Logger for "server=IMAP" and
another one for "server=POP3, SMTP etc.".
>
> > 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?
Agree on this. Wait a bit please. I'm working on a new set of interfaces
to improve recursiveness modifing the Contextualizable/Configurable
pattern.
>
> > 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.
Wrong. Indepentence is guarantee thanks to the init() run() pattern.
During init you are not guarantee to have any block already instantiated
but you can ask and be provided with a valid instance of a block. During
runtime you are guarantee that every block you need were alreary
instantiated and initializated.
The only problem can occur if block A, during init time, ask for an
instance of block B which need block A. The same thing can happend
during runtime: if the mail server needs to log an error and the logger
is configured to send a mail for that error...
There is no way I can see to avoid this loops except a topological check
during startup I'll implement later.
> 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?
Beeing Recontextualizable can be an hard task so I prefere, at least at
the beginning to let people write simplier blocks. Avalon will be able
to recreate instances of needed block when configuration are changed.
Of course the more Recontextualizable blocks there are the best. Maybe
in the future we'll force blocks to be reconfigurable.
>
> > + 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.
+1
I've updated the code and will upload it next MILLENIUM :)
>
> > 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
>
Thanks for your interest.
Best wishes for the new year to all of you!
Federico
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/>
Problems?: [EMAIL PROTECTED]
