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

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

Well, I've fixed the problem with saving the properties, and I can now 
save anything string like that you fancy to ~/.platemailrc.

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

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.

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.

Cheers,
dgs.