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

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

Neil Campbell wrote:
> On Tuesday 15 March 2005 00:05, David Stocks wrote:
> 
>>Well, I've fixed the problem with saving the properties, and I can now
>>save anything string like that you fancy to ~/.platemailrc.
> 
> 
> Excellent stuff.
> 
> 
>>To add an object:
>>1) implement the interface platemail.registry.RegistryInterface
>>   - this basically means adding the function register(), and a
>>Java.Util.Properties object
>>
>>2) have something call this, namely the cli interface
>>
>>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);

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

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.

> 
>>I think that a testing framework would be useful here; I've created a
>>test script which just pipes the input in but I have to do this outside
>>Eclipse since I don't know how to make eclipse do this.  Actually, I've
>>pretty much moved back to xemacs anyway, but I'd be interested to look
>>at unit testing.
> 
> 
> Yay!  Anything you can do by way of automatable testing would be very good.  
> As for Eclipse, I tend to run everything in a normal shell anyway, because 
> I'm not keen on how Eclipse handles it (and it doesn't colour my prompt 
> either).
> 

To be honest I'm always a little annoyed that I loose so much screen 
space; even in xemacs's compile frame you loose the bottom 5 lines of 
the screen (which is why I normally have another windows setup to 
compile/run).  You loose code space, and you don't really get to see 
error messages either.  Perhaps a bigger monitor would fix this, though 
I already have a 19" and that should be fine.  I imagine that this would 
be useful to work dual-headed, but I doubt that eclipse will like itself 
being split like that.

> 
>>The next, more complex, thing to do is to implement the reloading code.
>>  I'm thinking that this should be done by adding a constructor method
>>that takes a Properties object.  This gets more complex if there are
>>dependencies; for example POP3MailSource taking a MessageStore argument.
>>  It'd be possible to save such dependancies, however this could get
>>into loops etc. and probably is best avoided if it's possible to keep
>>things simple.
> 
> 
> I think if there are any cyclic dependencies, it's a problem with the object 
> hierarchy anyway, so the persistence code shouldn't have to worry about that.  
> The structure of the objects that need to be saved should be fairly simple, 
> and if this isn't the case lets refactor them rather than muddying the 
> load/save code.  I'm guessing that simple dependencies shouldn't be too 
> tricky to handle.
> 
> 
>>What's the point behind the MessageStore argument?  Is it possible to
>>have more than one of them?  It seems that the kernel has one of these,
>>which I presume is the root of all mail storage.  If there is only on
>>mailstore then it shouldn't be necessary to pass it as an argument to
>>the constructor.  If you've just done this to allow the created
>>mailsource (ie POP3MailSource) to hold a reference to the root, then
>>it's probably worth doing this some other way, since when the registry
>>does the restore it doesn't naturally have this reference.  It could
>>probably derive it from the global kernel reference, however the child
>>POP3MailSource could just do that itself anyway; it seems redundant and
>>unless there's something else going on here then I think that we should
>>bin that argument.
> 
> 
> Yes, at present there will only be one MessageStore, and it will be the one 
> the kernel has a reference to.  I can't recall exactly why the POP3MailSource 
> has a reference to it (and sourceforge's CVS seems to playing up at the 
> moment), but it's possible that it can be factored out - if you can do that 
> cleanly then by all means feel free.
> 
> 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.

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.

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)

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

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.

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