Terminology, Or: The Nature of Channels (was: Re: Channel sessions)

[olafBuddenhagen]

Hi,

On Fri, Aug 24, 2007 at 02:14:38PM +0200, Carl Fredrik Hammar wrote:
> <olafBuddenhagen@gmx.net> writes:
> > On Wed, Aug 22, 2007 at 05:23:45PM +0200, Carl Fredrik Hammar wrote:
> >> <olafBuddenhagen@gmx.net> writes:

> >> > Channel instances are pretty much of an internal detail IMHO.
> >> > When a user thinks of setting up a channel, he doesn't care about
> >> > individual client connections; it's the whole entity he thinks
> >> > about.
> >> >
> >> > Also, consider stores: The store is the whole entity, not some
> >> > client connection. The channel is the whole entity, not some
> >> > individual connection; why should it be anything else? Really,
> >> > the static setup is the most visible, most obvious part of the
> >> > concept; it doesn't make any sense to use the generic term
> >> > "channel" for anything else.
> >> >
> >> > I *strongly* object to any other use.
> >> 
> >> Fortunately this terminology does not need to surface to users of
> >> channelio, for them there is no need to distinguish the hub from
> >> the file it's sits on.  But for our discussion and in the
> >> implementation we must distinguish them.
> >
> > The fact that a pure end user needs less precise terminology,
> > doesn't mean it's OK to use the same terms in a different meaning.
> > That would be *extremely* confusing.
> 
> I didn't suggest that term should have a different meaning for users.
> My point was that the term `hub' doesn't need to be exposed to
> end-users, because its mostly an internal matter for libchannel and
> users of the library, like channelio.

Maybe -- I think we might have some misunderstanding about that term;
see below.

Anyways, I'm not sure why you even brought it up in this context. The
actual discussion was about channels vs. channel instances.

I think to sort this out for good, it's necessary to illustrate that
there are three levels involved with channels: The first one is the
actual code implementing the various hubs/elements, living in the
modules somewhere on disk. The second level comes into being when
channel stacks are set up using translators. These are still passive;
they sit there, having various properties, but usually not doing much.
The third level are active instances, that get created when clients
connect. Many things at level three are per connection/client/instance,
but not everything.

(Note that this structure is actually identical for stores -- only the
second instantiation is less involved for stores, as they presently
provide no facilities for handling multiple clients in a sophisticated
manner.)

Now it is obvious that there must be confusion: OO-terminology just
isn't suitable for such a three level/double instantiation system -- or
at least I have no clue how it can be applied in such a context...

However, this is only part of the problem. The main dispute I think is
about the relative importance of the levels: You are focusing on the
third level, and the second instantiation, and centering all terminology
around that; neglecting the distinction between level 1 and level 2, and
the first instantiation between these. (Most notably, using the term
"channel" for individual client instance.) From the perspective of the
channel implementation, the second instantiation is indeed the more
interesting one, where all the stuff happens. Yet centering the
terminology around that is wrong IMHO: It doesn't make sense from the
user's perspective.

The user doesn't really care about the second instantiation at all. When
the user sets up a channel stack, he does the first instantiation. The
level 2 facility resulting from that -- the filysystem node providing a
channel interface -- is already the end result from the user's point of
view; *this* is what he considers a channel. The user doesn't care nor
need to know, that most of the actual mechanisms get active only later,
when clients connect.

Think about stores: A store is *not* something that comes into being
only the moment some client connects to the store translator. Rather, a
store is a static object, described by the store translator(s) layered
on top of some device. When clients connect, they open this store so
they can perform actions on it; but the store itself exists independant
of any clients. The same way, a channel must be a static object
described by the translator setup. When a client connects, this does
*not* create a new channel. It only creates a new connection, a new
session, whatever you call it. (I previously used the term "channel
instance" for that, but I realize now that even that might be
confusing...)

If you really want to use OO terminology, I strongly suggest centering
it around the first instantiation, i.e. use class-level terms for the
implementations of the channel element types, and object-level terms for
the element instances sitting in the channel translators. However,
better even don't use OO terms at all: I don't think channels really fit
the OO model. And even if they did, OO terminology is not intuitive at
all, except for people already familiar with it...

> >> Also, with stores things are much easier.  Every client operates on
> >> the same store and changes made to it is seen by all clients, i.e.
> >> there is only a single store instance.  The amount of client state
> >> is also minimal, only an offset is needed.  So I don't think its
> >> fair to draw analogies between channels and stores.
> >
> > One being simpler than the other doesn't mean we are not allowed to
> > draw analogies. It's perfectly reasonable and desirable to use
> > equivalent terms for eqivalent concepts, regardless of the fact that
> > channels need additional concepts.
> 
> What you say is obviously true, but what I meant is that stores and
> channels aren't equivalent concepts (at least with my terminology),
> and that therefore the analogies weren't valid.

That was precisely tha point: As most of the concepts are equivalent,
that should be reflected in equivalent terminology :-) Only those
concepts that exist only for one or only the other, should get
individual terms. And most importantly, equivalent terms should *never*
be used for different concepts in a similar context.

> > Also, I'm not really convinced of stores being inherently simpler.
> > It's true that in most cases, the implicit junction at the top of
> > the store stack is fine; but I guess one could construct cases where
> > having the junction further down in the stack would be desirable. I
> > think the main reason why such considerations don't seem relevant
> > for stores (and thus the current store framework doesn't handle such
> > things), is that usually stores are used as backends for a
> > filesystem, and filesystems expect exclusive access to the store
> > anyways -- you just don't have multiple store client instances in
> > the normal case.
> 
> Stores *are* inherently simpler when it comes to handling multiple
> clients.  A store is shared between clients, modifications will be
> seen by other clients.  This property is the same for all stores,
> which allows the storeio to handle them uniformly.  The only client
> state ever needed is an offset, which can be communicated through the
> io interface, so it only needs to be maintained by storeio.
> 
> This also means that stores handle multiple clients just fine.  There
> is simply no need for stores to have a notion of different clients.
> (storeio does need it of course.)
> 
> The only stores that might violate this property would be stores where
> changes are kept private to clients.  But I'm not sure if this is
> useful enough to warrant complicating store sessions.  This could
> possibly be handled by storeio as a special case.  It wouldn't be a
> problem in a store channel-package.

The point was that while the existing stores do not need very elaborate
handling of multiple clients, it is concievable at least in theory that
some might require it. (I'm still not sure whether it is ever necessary
in practice...) The uniform handling of multiple clients simplifies the
implementation, but is not really a conceptual difference.

> > In fact, as you pointed out yourself in the beginning, stores can be
> > considered a special case of channels; and once the channel
> > framework is matured a bit, it will probably be desirable to
> > reimplement stores as a channel package...
> 
> libchannel would probably need some changes to handle stores as well,
> but I think it would be worth while doing it.  I'll explain how stores
> would fit into libchannel.  Perhaps it will clear up the difference
> between channels and stores.
> 
> A store would be an end-point which a client communicates with through
> a channel.

Well, using the terminology I suggest, stores are just a special case of
channels; and clients communicate with them through channel sessions or
whatever we want to call that...

> Such store channels differ from other channels in that they implement
> seeking, mmapping and paging, and that they may be sparse.

I wasn't aware that stores implement things like sparseness... I don't
think these are really necessary when using stores as a backend for
filesystems, are they? Maybe they were already designed with broader use
cases in mind...

> Calling a store a special channel would be wrong IMHO, since different
> client receive different streams depending on their current offset.

Well, in case of stores, the offset decides which client gets what data;
for other channels, it depends on other things, like the order of access
for a fifo for example... These are all specific cases of the same
general concept IMHO: Having a common backend, and some intermediary
(junction) that can multiplex multiple client sessions.

> > Yeah, I think I understand what you mean by type. I still don't get
> > the distinction to "class", though. I'm ignoring "class" for now;
> > hope it doesn't cause confusion.
> 
> It shouldn't confuse things.  The distinction between type and class
> is mostly only relevant in the implementation, where type usually
> refers to the name of the class, rather than the data structure
> itself.
> 
> Since the distinction isn't very useful, it might be a good idea to
> separate them and let class mean package.  I think this would be more
> appropriate in the end, but for now lets keep things as it is in
> libstore.

I wonder if it would be too confusing to use "type" for several things
in different combinations, e.g. call the individual classes within a
package "element types", and call the common interface implemented by
all classes in a package "channel type" or something like that...

> > BTW, you used the term "elements" above. How about using this
> > instead of "hub"? Seems more natural...
> 
> I don't think `element' makes sense out of context.  It works when you
> say ``stack element'', but ``channel element'' seems to mean channel
> rather a than channel hub.

Well, I don't really see that. To me, "element" much more sounds like a
piece of a chain, than hub does. But well, I'm pretty uncertain what is
actually more useful right now...

> How about `spec'.  It captures the fact that the mainly used when
> creating new channels.  To make it a more firm concept channels should
> not be able modify it.  And to refer to all channels created from a
> spec, perhaps simply saying `layer' would suffice.
> 
> Coordination between channels in a layer can be handled in a hook,
> which the spec holds a reference to so it can provide it to channels
> when they are created.  I think this makes sense, since it's mostly
> junctions that need such coordination.
> 
> I think this would fit a bit better into your intuitive terminology,
> while still keeping my emphasis that channel is primarily a per-client
> entity.

Well, I totally disagree on that terminology. As I explained multiple
times, I think it would be a very very bad idea to use the term
"channel" for any level 3, per-instance facility.

"Spec" is indiscutable. It is too abstract, and what's worse, it would
even further marginalise the first instantiation.

I am unsure about layers. I think it could be used in various
combinations. Primarily, I think of layers as level 2 objects: The
channel stack is composed of layers. However, besides of these passive
layers, one might think of active layers at level 3, as the sum of all
the client instances of one passive layer. (As opposed to element or
hub, referring to a single instance, in those contexts where the
distinction is important.) On the other side, at layer 1 we have the
implementations for various layer types.

I quite like the passive/active terminology to clearly distinguish
between level 2 and level 3, or first an second instantiation
respectively; and "implementation" for level 1 also seems OK, though I'm
not sure it's the best word. I think these adjectives could be used to
distinguish between derived facilities at various levels also in other
cases -- maybe even active and passive channels... It might actually be
clearer than using totally distinct term for each layer, which I
previously attempted.

-antrik-