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

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

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.

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

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

Neil