Hello,
<[EMAIL PROTECTED]> writes:
> Hi,
>
> On Mon, Aug 13, 2007 at 03:08:27PM +0200, Carl Fredrik Hammar wrote:
>> <[EMAIL PROTECTED]> writes:
>
>> 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.
>> > A channel module is a single unit implementing the channel
>> > interface, running within libchannel or in a channel translator. It
>> > has a client side, which can be access through a filesystem node or
>> > through libchannel; and a device side, which can access either a
>> > Mach device, or the client side of another channel module. A channel
>> > stack is a layering of several channel translators/modules.
>>
>> This object I have opted to call a hub, ``module'' would perhaps be a
>> bit better. However, I don't want to stray to much from libstore's
>> terminology. And in libstore module is the shared object containing a
>> class that can be loaded dynamically.
>
> Hm... Haven't distinguished between these up till now. Is it necessary
> to avoid ambiguity?...
>
> [...]
>
> 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.
I addition to its normal usage, a type is simply a name of a class,
and is pretty much only used to look up the class it names. Of course
the term is used for channels and hubs created from the class.
A class' main purpose is simply to create hubs of its type, i.e. it
supplies a pointer to a function that can fill in any type-specific
parts of a hub. Their is only one class per type and is static and
constant object. As an auxiliary service, it also holds any constant
data shared by all hubs and channels of the same type, which is mostly
a bunch of function hooks that determines the behavior of the
channels, these are referred to as methods.
A class is resides in a module, which is simply an archive that is
either already linked into the translator or is dynamically loadable.
A hub's purpose is to open channels and to coordinate them if they
need to access a shared resource. Unlike a class, there may be
several and they are not constant nor static. Parameters given when
it was created determines which end-point channels are connected to,
e.g. one hub of type ``device'' may open channels to /dev/dsp, while
another might open channels to /dev/eth0.
Our discussion is not on a low enough level to warrant use of some of
these, but hopefully it will explain my reluctance to use them in any
other sense. For our discussion type and class can be considered
synonymous. If you'd like you can use module instead of hub, since
it's likely not to be confused with its other use, but I won't (for
now.)
>> > Why can't --buffer or --no-buffer be used? In storeio, you also have
>> > a number of optional flags, and if you give several of them, you get
>> > implicit layering, although you only set a single translator --
>> > without using the "unwieldy" layering syntax...
>>
>> Yes, that is an option in many cases. But for buffering, position in
>> the stack may be crucial. Consider a tee, buffer, device stack, where
>> the tee will only open a single channel to the buffer.
>
> Well, when implicitely selecting several modules where order is relevant
> (which I think can happen with storeio as well), simply establish a
> fixed order; if for some reason a different order is necessary, one can
> still stack several translators, or use the layering syntax...
>
> BTW, I think junctions probably should never be specified with some
> options, but rather always by explicit translator stacking.
When combining both of your statements there isn't a problem. Buffer
position will probably only matter in stacks with junctions.
But you must acknowledge that stacks containing junctions can be
mighty complicated to specify.
>> If the buffer were on top, there would have to be one buffer per
>> channel, which is redundant since the same stream is passing through
>> all of them.
>
> I think there are cases where having individual buffers per instance
> could be desirable.
Well
