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

[David S. <ds...@in...>]

Neil Campbell wrote:
> 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.
> 

This was actually what I was really thinking of anyway.  I don't know 
where the static constructor idea came from.

[...]

> 
> 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 don't think that the reflection really needs to do much; just create 
an instance of the named class.  So all we're doing is creating a 
factory which does this, and passes the

In summary:

public void load(InputStream in) {
   Properties prop;
   PlatemailRegistryFactory factory;

   prop.load(in);
   factory.create(prop, kernelRef);
}

class PlatemailRegistryFactory {

  public static void create(Properties prop, PlatemailKernel kernelRef) {
     Object obj = new (Class.forName(prop.get("type")))(prop, kernelRef);
  }
}

Actually, I don't know much about reflection (that's quite obviously a 
guess at the syntax), so maybe a switch statement would do in the mean time.

> 
>>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.
> 

That would be useful, though it's probably worth sending such account 
details off-list.

> 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.
> 

Yeah, I've head of the UW IMAP server.  Perhaps I should look into that ;)

> 
>>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.
> 
> 

Surely this "mounting" feature is exactly what you're talking about. 
Should this be implemented at the MessageStore level, rather than by 
creating an alternate, MessageStore-level concept.  Indeed, the 
underlying format should be hidden behind a driver abstraction, so all 
you'd need was to specify the type of driver associated with each 
MessageStore.

Probably not important right now though.

>>>>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?
> 

Yes, but you don't need dependency checking for that.  You just need a 
text reference in the MailSource and runtime checking, since these two 
datatypes are separate anyway (we're not storing messages inside the .rc 
file).  This would only break if the message store didn't exist, in 
which case something's been corrupted and all bets are off anyway.

The issue is how we add the MessageStores, which is probably independent 
of other things.  Thus, we have the kernel do it's own setup;

KernelConstructor() {
   reload mail objects (sources etc)
   scan all files in ~/mail
   for each file do
     try to identify it heuristically for each driver
     if a driver claims it, use the driver to reload relevant state data
   end for
}

dgs.
-- 
David Stocks
Institute of Perception, Action and Behaviour
School of Informatics, University of Edinburgh
+44 (0)131 651 3436