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

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

Neil Campbell wrote:
> On Tuesday 15 March 2005 13:14, David Stocks wrote:
> 
>>>>That's pretty much it.  It's currently only implemented for
>>>>addpopaccount, since that's the only thing I currently use.  Which other
>>>>objects do you believe need saved?
>>>
>>>I think the best approach will be to put the code in with just that
>>>object saved, and we can add code as needed for other objects.  For
>>>example, in my current piece of work I'll need the IMAPMailSource data to
>>>get saved, but I've changed that quite a bit so there's not much point in
>>>you adding a method to it at this stage.
>>
>>It's really simple to add, since all you need to do is call
>>Properties.put(String, String) for each data item you want saved.
>>
>>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.

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

> 
>>This means that the object can't require any information that isn't
>>either saved or accessible from an initialised but otherwise blank
>>kernel, which I think is a semantically correct approach anyway.
> 
> 
> Yes, that sounds perfectly reasonable.
> 
> 
[...]
> 
> I've never been convinced that running it in Eclipse really gives you any 
> benefit.  My preferred approach is to keep an editor on one screen and a 
> terminal for running it on the other.
> 

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?

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

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.

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

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

> 
>>Accordingly, we should have a definite idea about what state an
>>initialised but "blank" kernel is in; mainly I'm thinking that this
>>holds a reference to all of the functionally registered things (which
>>interfaces are available, which commands for the cli etc).
>>
>>I'm inclined to think that there should be a definite "root" to the
>>mailstore, that isn't going to change anytime soon.  This should
>>probably be invisible to the user (ie not a part of a swing JTree or
>>anything).  This would allow for later addition of multiple mail stores
>>(a la Thunderbird, which separates IMAP accounts, POP, news, local etc)
> 
> 
> This is already how it works in Platemail (except for news support and so on, 
> of course).
> 
> 
>>I'm also thinking that the kernel itself should be savable, since it
>>should save as a generic saving point for all of these "misc" items
>>(preferred UI, default mail account etc).
> 
> 
> Yep.
> 
> 
>>Right, I'm off to learn fascinating things about how Rhinolophus
>>ferrumequinm's use of constant frequency echo's allows it to use the
>>doppler effect to detect moth flight vectors.  More interesting than I
>>imagine it sounds.
> 
> 
> You should have asked me - I'm an expert in that field.
> 

Turns out it wasn't that interesting.  Meh.

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