Sounds sane, except that the the term StoreEntry is utterly
inappropriate for this kind of struct.. and I will try to read your code
changes if that is what you are asking for.
Notes:
Multiple clients on a single FS object or internal object is quite
trivial.
Mutliple clients on a single server object is the tricky business. But I
doubt the value of this, especially so if partial object store get's
implemented. Most times it seems to generate more problems than it
solves (stalled connections, exessive memory use, and probably higher
bandwidth usage due to stalled connections causing more reloads than
needed)
/Henrik
Adrian Chadd wrote:
>
> On Mon, Dec 18, 2000, Henrik Nordstrom wrote:
> > Adrian Chadd wrote:
> >
> > > > Henrik Wrote:
> > > > From your talk it seems you envision having the object store the central
> > > > point connecting everything, while I have it a little on the side of
> > > > things..
> > >
> > > Nope, we share the same view. The object store is meant to simply be
> > > one of the reply types..
> >
> > Good.
>
> Ok. I'm slowly ripping things up in the modio branch. I'm aiming
> to collapse the memobject, storeclient and storeentry into one
> single struct which describes a single client/server pair.
> The 'server' is described by a bunch of functions and a datapointer
> for state, and the client accesses the server though this.
>
> The StoreEntry now becomes transient during the course of a connection
> (can you say "StoreTree" ?) and a large chunk of the code in store_client
> becomes unused because we're only supporting one store client per
> StoreEntry. This is ok because if a FS wants to support multiple clients
> on a single backing object, it can just hand out multiple StoreEntry's
> and handle multiplexing the dataflow itself..
>
> Does this sound sane ?
>
> Henrik, do you mind checking it out and seeing if my design
> is heading in the right direction?
>
> --
> Adrian Chadd "Here's five for the cake, and
> <adrian@creative.net.au> five to buy a clue."
> - Ryan, Whatever it Takes
Received on Mon Dec 18 2000 - 16:29:41 MST
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:13:05 MST