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

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

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.

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

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

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

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.

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

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

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