Hi Simon,
Had a long weekend so just picking up this thread. Looks like a really
useful discussion and I too like the requirement driven approach. I
have a
few to add/comment on. It seems that a plugin resolves to a
component type
or binding, i.e. what the assembly model refers to as extensions,
so that is
what I have in my mind.
IMHO you can package an extension as a plugin, but you can also package
an extension as >1 plugin, or you could package a number of extensions
in just 1 plugin. So I think there should be a level of decoupling
there...
6. There will need to be some kind of manager thingie to keep
track of plugins and their state at runtime.
Extensions should be able to constribute information to the in
memory model,
for example, via annotations.
[deletia]
...and this is why :) There are number of responsibilities of an
extension - which you accurately describe - and there are a number
of responsibilities of a plugin, related to configuration and lifecycle
and I think it would be a Good Thing to keep them as separate
development
efforts. What do you think?
[deletia]
+1 for a simple lifecycle interface. What kind of parameters do
you have
in mind?
Will also need some hosting abstraction to tie in with these lifetime
interfaces, for example, it might be useful for an extension to
know when it
can observe caching semantics. Also has an impact on the (re)
deployment
story, for example, we may want to deploy extensions without
stopping the
server so we need to be able to do this and have the extension come up
cleany. These don't need to be at the top of the list.
+1
[deletia]
I would extend the extra requirement added by JSD to include all
runtime
error, logging and audit requirements.
+1. On the subject of audit, to do successful auditing we need to have
access to the concept of an identity :) Has there been any discussion
about this already?
Oisin, good idea to put all this up on the wiki. I'll check there
when you
have added you first tranche and add comments in.
Will email the list when it's in place.
cheers
--oh
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
