Persistency, settings

Hi all,

While integrating in AIDA, I found  problem with current way  Swazoo
deals with settings,
that is a SiteRegistry. While thinking how to solve that, I started to
think about Swazoo persistence in broader sense.

In general we need to make persistent many things in Swazoo:

1. global settings
2. site settings
3. resources settings
4. hierarchy of resources (sites and their resource hierarchy)
5. session, security, ...
6. other resource needs

Swazoo should deal with following persistency types:

1. image snapshot
2. ODBMS
3. RDBMS
4. files (BOSS, XML like now, ...)

Swazoo currently support 4. and partially 1., while AIDA 1. and 2.
I think we must support (or provide hooks) for all 4 methods. Also we
must support 1., all other types should be optional.

To achive that we need to make some kind of plugin support for setting
and configuration of Swazoo. Currenty we have only SiteRegistry with
sites.cnf file and all configuration is done around that. I think the
configuration through sites.cnf should be optional. sites.cnf is IMHO
needed only with headless Swazoo with only persistence type 4. All other
persistence types don't need file based configuration. And I admit, I
hate any more files except .im and .cha . :)

I propose to add settings instvar in Resource as a general way to save
various settings, for Swazoo and for resource internal needs. Let we add
settings to SiteRegistry too (or somewhere else), for global Swazoo
settings for all sites. This instvar can be a simple Dictionary or we
can introduce a new class: Settings.

Now how to store those settings persistently? For persistence type 1 and
2 and partialy 3 (with GLORP for instance) it is easy, 4 is harder.

So whole question is how to extend current way of configuration/settings
to be more flexible and support of all 4 persistence types. I need your
help here fast to integrate AIDA configuration/settings (image and
Gemstone based) with Swazoo.

Any ideas?

Janko

Janko Mivsek wrote:

> I propose to add settings instvar in Resource as a general way to save
> various settings, for Swazoo and for resource internal needs. Let we
> add settings to SiteRegistry too (or somewhere else), for global
> Swazoo settings for all sites. This instvar can be a simple Dictionary
> or we can introduce a new class: Settings.

Instead of adding an instance variable -- and one that has to be set
per-resource -- we should make a transparent composite resource that
sets a data source in the environment data, much like the
SessionResource does currently.  After all, this is the Swazoo way.  :)
 That way, any resources under that DataSourceResource will
automagically refer to the same data source.

To do this, you'll have to create a class that encapsulates the data
source access, and you should be able to re-use that object for
something like a SiteRegistry, sessions, etc.


Ken

Ken Treis wrote

I agree. Data source is a common property of a set of resources and
should be represented as a meta-resource in resource tree.
ResourceSource seems like an appropriate name :) This also handles the
problem of bootstraping the resource tree nicely.

When unpickling itself, a Resource needs to:
a) look up its data source
b) initialize itself from data source. This may involve creating
children of CompositeResource and unpickling them as well

For instance, let's say that we have XMLFileResourceSource as root of
resource tree. It parses XML configuration file and creates children,
namely Sites and possibly other ResourceSources, which may define
different configuration sources. It then sends initialization messages
to Sites, which in turn initialize their Servers (and yes, maybe servers
should be resources, too :), etc.

So, I propose something like

Resource <- ResourceSource <- ( NullResourceSource, XMLResourceSource .... )

NullResourceSource is parent of Resources persisted within OODB and does
nothing (we may as well just use nil). XMLResourceSource parses XML
file, creates children and sends them initialization messages, according
to XML tags. As an icing on the cake we may also have
URLResourceSources, etc ...

To summarize: it seems like a problem of pickling/unpickling an object
tree from variety of data sources. We need lookup (which is a resource
lookup in hirearchy), pickling and unpickling.