Re: Fwd: Re: [Platemail-developer] Properties

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

On Tuesday 15 March 2005 15:07, David Stocks wrote:
> >>Reconstruction is probably more difficult, since it will mean adding a
> >>static method to each loadable class.  I'm in favour of making this a
> >>rigid interface, something like:
> >>
> >>static public load(Properties prop, PlatemailKernel kernelRef);
> >
> > Can't we have a single method somewhere that does this?  It doesn't seem
> > quite right to require each class to provide a static method.
>
> Perhaps.  Thing is I could imagine some of this getting quite object
> specific, and I'm not sure it's worth making generic unless we have a
> more detailed reason to do so.  Certainly, for the types of things that
> I'm currently thinking about saving/reloading it seems overkill.  As a
> man with a big beard once said: KISS.

This method would only really need to decide which object to create - then it 
can pass the properties object to a constructor to instantiate the 
appropriate class.  Otherwise, you presumably have a method which selects 
which class to call this static method on, then you call into that which will 
basically create you an object in the same way anyway.

> >>Thus, when we do the reload operation inside PlatemailRegistry, it just
> >>iterates through each saved object and calls the appropriate class.
> >>Something like this:
> >>
> >>for each object in InStream do
> >>   prop = deserialise Properties object
> >>   mailObj = Reflection.getObjectType(prop.type)
> >>   mailObject.load(prop, kernelRef)
> >>end
> >
> > Could you expand on the 'Reflection.getObjectType(prop.type)' line
> > please?
>
> The idea was that the object would have a field:
>
> type=POP3MailSource
>
> and then we would need a factory which created the suitable thing using
> reflection.  This we do:
>
> MailObj mailObj; // pointer to generic mail structure
> mailObj = MailObjFactory(prop.get("type")) // create new POP3MailSource
> mailObj.load(prop, kernelRef) // call local setup mechanism
>
> Though we'd need a common hierarchy for this, which I've just realised
> that we don't have.  That could make things less clean, since we'd need
> to push the load() call into the code that does object-specific things
> (the factory).

I'm not keen on reflection, generally.  I think once you've determined the 
type from the string you might be better off deciding yourself which object 
to create, rather than using the old Class.forName sort of thing.

Having said that, I appreciate that in the future we may have an unknown 
number of classes, if it becomes properly configurable.  I'll leave it to you 
decide which side of the simplicity/extensibility tradeoff we want to sit on 
for the moment.

> I had a brief look at JUnit, however it seems more specialised toward
> self-contained classses.  Do you know of anything intended for
> system-wide tests?

http://www.junit.org/news/extension/index.htm has a few things, none of which 
I've really looked at in detail.  I suppose it depends on how you want to 
test the system - JUnit can test larger pieces of functionality, but if you 
want to run the test from the user's point of view then scripts and expect 
are probably the way forward (for the CLI at any rate; there are some gui 
testing tools available too).

My preference for these would probably be to standardise on expect, or perhaps 
the python port of expect, which would free us from using tcl.  I don't know 
how mature the python one is.

> I supose I could expand on my shell scripts, however they aren't
> currently automatically verified.  Perhaps we also should create a test
> pop mail account on yahoo for this purpose (thought they don't offer IMAP).

I've got a test account on thebatcave.org.uk, I can easily create more.  These 
work for pop and imap.

For some more stress-testing, there's also a free IMAP server run by one of 
the american universities (possibly UW) that you can play with.  I've got it 
bookmarked at home somewhere.

> Actually, perhaps I just need to focus unit tests on the correct bit;
> for example creating unit tests against the console ui should be able to
> test anything.

In theory yes, although it's often difficult to test an isolated piece of 
functionality.

> >>>If it does genuinely need a MessageStore reference though, I'd like the
> >>>registry stuff to be able to cope with a dependency like that.  It is
> >>>conceivable that at some point I'll want to support multiple message
> >>>stores within a single Platemail instance, so it would be necessary to
> >>>distinguish between them.  In any case, it seems likely that there will
> >>>be cause for some sort of dependency information required at some point,
> >>>because the obejcts won't all remain unrelated.
> >>
> >>I'm happy with the MessageStore (MailStore?) needing a reference to the
> >>kernel, I just think that it's best to have everything it needs
> >>accessible from that.
> >
> > Is that necessarily appropriate in a world with one kernel and multiple
> > message stores though?
>
> I'm not sure as to the point on multiple mailstores.  If each account
> has it's own "folder" (that's probably an inappropriate term for this)
> within a hidden root element, then you've got everthing you need.  If
> you want to attach another type of thing, then you just add in a new
> child of the root element.

Yes, but you might want to keep some on disk and some in a database, for 
example.  There isn't really a facility (nor is there likely to be soon) for 
'mounting' stores within one another.

> >>Again, since we can't guarantee the order in which objects are reloaded,
> >>it's probably also important that the reloading process is random
> >>access, which means that no object can make explicit assumptions about
> >>the kernel having loaded anything.
> >
> > Presumably you can arrange for all objects to be written after anything
> > that they depend on, can't you?
>
> Yes, but I suspect that way lies madness.  Can you write me a test case
> where this is strictly necessary?

Well, if you have a mail source that needs a message store, wouldn't you need 
to create the former after the latter?

Neil