On Nov 16, 2007 5:25 PM, Robert Burrell Donkin
<[EMAIL PROTECTED]> wrote:
> On Nov 7, 2007 1:53 PM, Danny Angus <[EMAIL PROTECTED]> wrote:
> > On 06/11/2007, Robert Burrell Donkin <[EMAIL PROTECTED]> wrote:
> >
> > > Zsombor suggests object storage.
> >
> > ...
> >
> > > (not sure i have a strong preference)
> > >
> > > opinions?
> >
> > There are two approaches, and they are mutually exclusive, they are..
> >
> > 1/ Start from a strongly typed and controlled structure (like
> > "UserMetaData") and extend it with each new use-case. This approach
> > might help to mitigate upgrade compatibility issues, but has an
> > analysis and design overhead.
> >
> > 2/ The other approach would be to go for the most general, which is
> > anything Serializable, and leave upgrade compatibility in the hands of
> > the gods.
> >
> > I would tend to come down on the side of 2/ because I'm not convinced
> > that we can justify the amount of engineering involved in 1, and I
> > already like the relaxed approach that servlet session has. You can
> > build rigour on top of a loose framework but not the other way around.
>
> sounds like there's a consensus in favour of option 2
>
> should probably recommend key domain namespacing (for example, JAMES
> properties should use keys starting org.apache.james)
>
> been having a think about this. would be good to use this API for
> other user related data for example the user sieve file. this means
> that would need to be able to store binary and textual documents. i
> suggest nio channels for the binary API and reader/writer for text
> documents and that isolate keyspaces are used (for example, the text
> document keyed org.apache.james.sieve would be different from a binary
> document or serialized property with the same name).
>
> opinions?
>
> anyone want to volunteer to create a basic implemenation?

no one seems keen to jump in so i'll take a look at this

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to