Re: Channel sessions

[Carl Fredrik Hammar]

Hello,

<olafBuddenhagen@gmx.net> writes:

> Hi,
>
> On Tue, Aug 14, 2007 at 02:15:46PM +0200, Carl Fredrik Hammar wrote:
>> <olafBuddenhagen@gmx.net> writes:
>> > On Mon, Aug 13, 2007 at 03:08:27PM +0200, Carl Fredrik Hammar wrote:
>
>> >> I will use channel for the object that a client interacts with,
>> >> i.e. one is created whenever the translator is opened.
>> >
>> > That is what I call a channel instance. You can also call it a
>> > channel session; but referring to an individual instance only as
>> > "channel" would be very confusing IMHO.
>> 
>> I have found the opposite very confusing or at least it has misguided
>> me in the past.  The word channel suggest that their is a only single
>> stream of data (in both directions) transferred between the two
>> end-points.  Associating it with the translator, gives the idea that
>> every client will receive the same data, i.e. opening a channel
>> subscribes a client to the channel.  I was under the impression that
>> this was the case for quite some time.
>> 
>> But I think we both agree is not always the desired behavior.  Instead
>> opening the translator should give the client a *new* communication
>> channel to the end-point.
>
> Well, we agree about the semantics; but I don't think that it should be
> reflected in some obscure terminology.
>
> 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.

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.

>> > Well, I can't make much of OO terminology; I'm still not really sure
>> > what you actually mean by a channel class... I hope you don't mind
>> > if I don't use these terms :-)
>> 
>> Lets take it from the top and see if it clears things up.
> [...]
>
> Sorry, I still don't understand what classes and types are supposed to
> be exactly :-( What's worse, I don't know whether they are compatible
> with my intuitive use of the terms. It seems to me that you are using
> them in relation to a specific hub; while I'm rather thinking about
> different kinds of channels (channel stacks), like audio channels or
> network channels.

Well I don't view them in relation to a specific hub (instance).
Because a hub produces only a specific type of channels, the type of
the hub becomes the type of its channels.

But I think you were getting at is that while I attach a type to a
single element in a channel stack, you view a type as a collection of
the various types (of my definition) that can be used together.

Examples of different types would be; `tee', `device', `audio-mixer'
or some such.

My definition is the one used in libstore, so I think we should stick
to that.

> An audio channel for example has some additional facilities aside from
> the generic channel stuff to control bitrates etc., and also requires
> specific semantics when merging/splitting instances. So an audio channel
> stack will most likely include some audio-specific hubs (perhaps in
> addition to some generic ones). A network channel stack will use
> network-specifc hubs. What term would you use to describe such stacks
> (and hubs) for handling particular kinds of data?

I guess I would call them channel types that handle a certain stream
type.  But it would be useful to handle this more firmly.

Lets call it a `package', a package would simply be a collection of
classes that can be used together.  It would be nice if each such
package had its own namespace instead of prefixing the name to classes
of the same package, e.g. the audio package would have one `tee' and
the network package another, instead of `audio-tee' and `net-tee'.

>> > I think there might be some cases, where some variant of fifo is
>> > most appropriate; but I'm not at all convinced that it's the most
>> > useful in the general case. In fact, my point was that there might
>> > not be such a thing as a general case here... Useful behaviour is
>> > just too type-specific I think.
>> 
>> Hmmm... yes, I think it might be best to simply make junctions read or
>> write only, and force the user to handle it appropriately.
>
> Yes, I believe that if there are any generic junctions, they probably
> should always be unidirectional. However, for specialized junctions
> handling specific kinds of channels, e.g. an audio junction, I think
> there might be some obvious combinations.

Agreed.

> What I wonder about is whether it's even useful to have any other than
> such specialized junctions...

I'm starting to think no.  Or at least not that is useful across
packages.  But there might be a need for a `generic' package that
deals with generic character devices, like /dev/zero, /dev/random and
input devices.  So now the question becomes ``Is there a useful
pairing of `generic' junctions?''

>> For a general purpose fifo I would split and merge requests, e.g.
>> merging two reads or splitting a write in two.  Of course this would
>> break up packets.  One way to get around it might be to introduce
>> packeting channels, that simply makes sure that each request is in
>> whole packets, buffering if that is not the case.
>
> Well, unless I'm missing something, I'd say you need that in any case
> for things like network channels... I don't see how one could handle
> network channels in any useful manner without awareness of packets.

Well it is obviously needed for all kinds of network junctions.  But
one might be able to use generic junctions if one layers a channel
that makes sure all reads and writes are in whole packets.

This would also be needed for audio channels, since a audio frame is 2
bytes long.

>> >> A modified version of three might work though, where the split and
>> >> join is in a single module that maintains two separate stacks.
>> >> Lets call this option four.
> [...]
>> For now I will go with option four, since it will work without adding
>> functionality to libchannel.  But client IDs should be definitely be
>> explored as an alternative.
>
> Are you sure that doesn't require additional functionality? It seems to
> me that handling such sub-modules actually requires quite a lot of
> additional infrastructure; maybe even more than client IDs... (Aside
> from the fact that it's not very elegant IMHO.)
>
> -antrik-

I'm not sure.

But I'm not sure it will be a problem, since our discussion seem to be
heading towards less generic code.

I'm starting to think that instead of providing generic junctions,
libchannel should provide code that can be shared between packages and
be used to piece together specialized junctions.  This would probably
make channelio much more user-friendly in the end.

Cheers,
  Fredrik