Persistence containers (was Why all the different string types?)

Jens Miltner wrote:

> So, essentially, there will always be only one instance of MacCvsX  
> running at a time, but this instance can handle multiple browser  
> windows and as such should be able to arbitrate the settings between  
> the browsers.
> And since this (the singleton-app)  is such a basic UI paradigm on  
> Mac OS, we can't just go ahead and launch multiple instances of  
> MacCvs...

Ok, thank you Oliver and Jens for clarifying.  Some ideas are starting 
to gel:

(1) Persistence should be a characteristic of a (persistence) container, 
not of data types.  Ideally, we should be able to use simple data types 
(int, float, boolean, String) and delegate to the container how to 
persist them and retrieve them.

(2) If we use the concept of a generalized persistence container, then 
we can have any number of them.  We can have one at application (global) 
scope, and one for *each* sandbox/instance/project/repository/local 
(pick the term you like.)  Each container should know how to persist and 
populate itself.

(3) Each individual setting that goes into a persistence container is 
just a simple data value of a defined data type.  It doesn't need to be 
identified as being of scope global (kNoClass) or of scope instance 
(kAddSettings), nor does it need to be of a specialized persistence data 
type like CPersistentBool.  It automatically becomes a persistent data 
value when it is added to a persistence container, and it becomes a 
persistent data value of a particular scope depending on *which* 
persistence container you put it in.  You can even have a data value of 
the exact same name in two or more persistence containers.  That would 
be the norm, actually, since all sandbox containers would likely have 
the same set of data values.

(4) To keep a persistence container generalized, the container itself 
should not have to understand that it is "higher" or "lower" in a 
persistence hierarchy than any other persistence container.  Each should 
be self-contained.  If a hierarchy exists, that hierarchy should be 
established external to the persistence container (perhaps in a 
persistence hierarchy tree.)  That may be more than is necessary; 
perhaps we only have a 2-level hierarchy, local and global.

(5) Which class or classes in the CvsGui class structure should contain 
a persistence container is really a different design decision from the 
implementation of the persistence container itself.  I'm really not 
well-versed enough in the entire CvsGui set of classes to make a 
well-informed decision there.  I notice in AppGlue that all platforms 
have an app class; that would seem a logical place for a global 
preferences container.  Would CCvsSandboxInfo be the correct place for a 
sandbox-level persistence container?

After writing all this, persistence containers seem to be just an 
in-memory representation for the persistent data values maintained in 
the file system.  Logical, I suppose, so we might as well take advantage 
of all the knowledge that has been accumulated in implementing those.

I'll come up with a straw-man implementation for a persistence container 
that we can kick around for ideas.

-- 
Guy Rouillier


 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/cvsgui-dev/

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/