Re: [Platemail-developer] Re: java and dynamic class loading

[Neil C. <ne...@th...>]

On Tuesday 27 September 2005 14:03, David Stocks wrote:
> Having all these files in a ~/.plplatemaillpluginsirectory was where my
> thought were heading to, however I have reservations:
>
> 1) how does this fit within the package structure?  It seems that moving
> them outside of the main source body would require having them as
> stand-alone units, rather than being part of a normal java package.

Not really, they can continue to be in packages whereever you put them.  It 
would probably make it clearer to have them in different packages, but that's 
no great problem as long as the right classes implement the appropriate 
interfaces.

> 2) are these really modular?  Are there hahardcodedeferences which would
> require access to the class files/srsrcn order to statically check+compile
> other units?

In the specific case of the console commands, I don't think anything calls 
them, and the things that they call are either parts of the console they 
belong to or parts of the platemail core, so we should be able to move them 
out.  Of course, they'll need access to whatever parts of the API (such as it 
is) that they use at compile time, similarly they'll need to know about the 
interface they implement, but that's to be expected.  Without both the module 
and Platemail knowing the interface between them, there can't be any 
interoperation, and equally if the module doesn't know how to talk to 
Platemail (how to extract parts of an Email, walk the folder structure, etc), 
then it can't do very much that's useful.

> 3) Does this create class veversioningssues?  Could we end up having and
> older version of the command used with a newer version of plplatemail

Ultimately yes, we'd need to introduce version numbers into Platemail and have 
any plugins know which versions they work with and so on.  

> A lot of this depends on really how modular the commands are.  And making
> them properly modular means removing *any* non-generic calls to them.  It
> should be the case that the module is started by plplatemailhrough a well
> defined entry point, and then has the ability to drive the main
> application.  Something like this:
>
> 1) plplatemailtarts
> 2) plplatemailcans $PLPLATEMAILRClpluginsloading each class encountered
> 3) for each class
> 3.1) call Class.foforNameukukrg...adaddpopaccount.register()
> 3.2) this will call uiuionsole.adaddCommand, or some other published entry
> point into the specific command
> 4) the console uiuiow has an extra command, which is really just a
> hahashmapetween the command name and it's invoke method.  Thus the user
> types
>
> > adaddpopaccount
>
> which sends a message to the corresponding class's "run" method:
>
> ((Command)mymyCommandListind("adaddpopaccount).run();

Yeah, that sounds about right.  How the 'registration' takes place will depend 
on what we're doing; for the simple case of the console commands I think the 
console just needs to instantiate each class using an appropriate constructor 
and then, as you say, add it its map of command names.  When we have a proper 
plugin architecture we'll have to think more carefully about what that 
requires, but I expect that plugins will be grouped into various types, each 
of which will have a slightly different interface and different points of 
invokation.

> this method can access (drive) plplatemail This "driving" will include
> access calls to whatever I/O is available.
>
> As a side point, I think that each command is really split in two parts;
> the conceptual "what it does" and the UIUIhow it talks to the user".  This
> would make it easier have differing I/O layers placed on the underlying
> functionality available to plplatemail You may already to this actually, I
> haven't looked.

I'm not quite sure what you're driving at here.  What the commands do it 
invoke some functionality in the core of platemail, and give the user some 
sort of response.  All of the 'what it does' goes in inside the kernel - 
downloading messages, searching through existing messages, etc.  The user 
interface just provides a way for the user to request that service.

> Now, in essence, I don't think this any of is a good idea.
>
> I don't believe that separating the core ("conceptual") functionality out
> into modules is a good idea.  Doing so really limits the interaction
> between the two -- this would mean building a rich functionality/APAPIhat
> the modules could drive, which I don't believe exists.  It could
> potentially create a dependency hell -- if it's possible for one module to
> rely on another then we instantly need some type of dependency tracking
> mechanism to guarantee that modules are loaded in the correct order and
> then everything gets complicated.

We don't want to separate the core functionality, we only want to separate the 
interface to it.  Think of Platemail as a black box which does stuff when you 
press buttons.  The buttons aren't part of the core, they're just a way to 
make your intentions known.  Similarly the console commands don't know or 
care how the internals of platemail work, they only need to know the 
interface between them.  The console commands are, in effect, outside the 
platemail box.  A rich graphical interface is also outside the box, it just 
provides the user with a slightly different means to press invoke parts of 
Platemail.

> I think what we really need is what we already have; an answer to the
> question: "how to I add an extra command?"
>
> As above, this is really two questions,
> 1) "how do I add extra functionality (conceptual command)?"
> 2) "how do I hook this extra functionality into the X uiui (where X:=
> {guguionsole})

The extra functionality should be inside Platemail, if it is independent of 
the user interface.  Otherwise, it should live in the user interface.  For 
example, Platemail should never provide a Swing widget for a gui to display; 
nor should it ever parse a users command.  What it should provide is the 
means to get hold of the data, for example to get hold of a particular email 
object, or a list of folders, or whatever.

> Now my thinking is that we want to have one specific registration point for
> the each place (1 the core functionality, 2 the guguilatform, 3 the console
> platform).

The gui and the console should both live outside the core, and the core should 
be blissfully unaware which of them (if either) exists.  Nothing should need 
to be registered for the core functionality, because it's all core, and built 
in.  Plugins will have to be registered because they do things beyond what 
platemail will do, such as (they scheme I'm currently looking at) moving 
messages between folders based on the results of running them through a perl 
or python script.

All plugins will probably be registered in the same way, but depending on 
which interface they inherit they'll be invoked at different times, for 
example you could imagine a plugin that filters mail and another that adds a 
random signature to the end of each outgoing mail.

That's sort of how I'd envisaged it, of course it's all open to suggestion 
because it hasn't been implemented, or even planned yet.

Neil