Mark: Just brainstorming some ideas here, for what would be a pretty substantial change the the core architecture, but might be less messy. Not necessarily proposing we do this for GK, but interesting to think about.

Right now, there are conferences, which connect to some number of environments (n-level trees), which are shared in different ways. Broadcasts go through environments, etc. Client-server and replicated environments exist, others possible.

Note that almost all environments are either used as what is basically a database table (i.e. toplevel nodes are unique key, kids of each node are attribute-value, generally homogenous across nodes), or collections of several database tables.

Now, what if we had instead...

• toplevel "environment" (lets call it a "context"), has no data, but defines interconnections with other processes (e.g. all session managers share the same context, each conference has its own context shared by all current users, etc.)
• contexts could be client-server, replicated, etc.
• rpc broadcasts go through these contexts (like now through environments), since its the contexts that maintain the connections
• each context can also hold any number of object lists, which are like current environments but hold just objects, identified by unique key, and having attribute-value pairs)
• creating the object lists in a context defines how they are shared (may be several variations possible?); notifiers etc. to monitor changes in an object list
• object lists would easily map onto metakit-backed storage, could define variations in terms of how they cache data, so they wouldn't need a complete copy but would fetch stuff on demand, etc.

Benefits...

• get rid of the complexities of the service, registry etc. stuff to simplify the overall structure (it does provide more generality, but do we need it?)
• contexts map nicely onto sessionmgrs/conferences
• having object lists (data) in contexts makes how they're shared more obvious, and just makes sense (of course a conference can have multiple types of data)
• doing object lists instead of generalized trees maps onto db tables easier, and reflects actual usage; could then add things like making changing multiple attributes at once for an object possible
• if replicated processes (e.g. conferences) want to also access a shared resource (e.g. centralized db), they can just open/connect to a second context

Chad -

It looks fantastic Mark. Just the kind of shift groupkit needs - it simplifies things a lot and makes room for expanding the whole idea of collaoborative sharing. I think the answer to do we need more generality is a big YES.

• This separates the function of discovering/joining the group from participating in the group which is an excellent improvement
• Object lists (more closely related to database tables as opposed to trees) are much more easily managed/isolated etc
• Unique keys is probably the only way to go in such an environment
• Relationships between objects and catering for those may need to be ironed out more
• Contexts also help to separate the concept of notification from data transfer.
• Large objects can be broken into two parts: the metadata and the real (heavy) data. Contexts could always have the most up-to-data metadata for objects but collect the heavy data on demand.

I have to say this is a real turn up, I dont think I would have been able to see this brilliant modification as I am just not as familiar with the whole concept as you are - let alone the finest details of gks' inner workings. It helps my plans greatly. I have been talking to Jean-Claude about metakit concurrency and am working on a client/server model which will probably give us what we want though I'm not 100% sure yet. Will need to put it through some extensive testing. In any event I dont think the mk4tcl extension will give us all the functionality we will need.

Excellent stuff, I look forward to more comments.

Mark:

Cool. :-) Time to start thrashing out a design for this, and see where that goes. Incr Tcl will be used for the building blocks... both Chad and I are happy with going that route, and given things like Tclkit its pretty easy to have available.

So I guess some new pages are in order to figure out the design for a Context and an ObjectList to start with anyway.