[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Channel sessions

From: olafBuddenhagen
Subject: Re: Channel sessions
Date: Thu, 23 Aug 2007 00:30:49 +0200
User-agent: Mutt/1.5.16 (2007-06-11)


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.

> 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.

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.

This however could quickly change, if the store concept is applied to
other use cases -- which would be very desirable IMHO: I believe there
is a whole class of translators (including "kitten" and "rollover", but
also gzip and some others) that would be useful to implement using
stores or some store-like facility.

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...

> > 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.

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.

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

I think it's less intuitive in the context of channels, but I'm fine
with sticking to it for consistency.

> > 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.

Well, that isn't optimal, as it doesn't catch the fact that all the hub
types in a package not only have some package-specific semantics, but
often also have a specific interface. (e.g. specific packeting
properties, specific control commands etc.)

But maybe it's clear enough. I'll stick to "package" for now.

BTW, you used the term "elements" above. How about using this instead of
"hub"? Seems more natural...

> 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'.

Well, how would that work in practice? I guess the channel interface
would require explicit namespace parameters in addition to the actual
names? And for the channel translators, one probably would need
subdirectories, like /hurd/audio/tee and /hurd/net/tee?

(Or do you think all channel translators should be set up using only
channelio with different module parameters?...)

Well, to be honest, I prefer the prefix variant -- not only because it
doesn't require special handling...

> > 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.

Yeah, we probably need a "generic" package with some universal modules
that should suffice to handle simple devices not having special needs.
But I don't think this package will be very large: What does it require
besides the mach device access and buffering hub types?

> > 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.

Well, can this really be handled by layering? And is there any advantage
in doing so? My impression is that packaging should be an inherent
property of all channel interfaces. But then, I haven't thought through
the details...

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

In fact, it depends on the settings: A typical stereo 16 bit stream for
example actually has 4 bytes per packet; 24 bit would have 6 bytes etc.

The difference to network packets is that audio packets have a fixed
size once the parameters are set, while network channels have a
different size for each packet.

> > 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.)
> 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.

Well yes: As I have argued, the actual semantics of junctions are quite
package specific. Yet the basic concept is generic, and the framework
needs to provide generic mechanisms for implementing specific junctions.
I'd say this should include generic mechanisms to faciliate implementing
specific stream pairing variants. (input/output, data/control etc.)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]