Hi, On Tue, Aug 14, 2007 at 02:15:46PM +0200, Carl Fredrik Hammar wrote: > <[EMAIL PROTECTED]> 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. > > 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. 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? > But you must acknowledge that stacks containing junctions can be > mighty complicated to specify. Of course. I don't consider that a problem, though. I'd say such stacks are a rather special thing anyways. > > 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. What I wonder about is whether it's even useful to have any other than such specialized junctions... > >> Yes, I am well aware of the differences. The out-tee is much, much > >> simpler. Handling the case when some channels of an in-tee aren't > >> so that other channels don't stall is tricky. > > > > I'm not sure there is any difference in this regard. I don't see why > > backends should provide any more guarantees about not stalling than > > frontends... > > The difference is in the difficulty in handling stalling, not whether > they stall or not. The problem is more that the client has control, > the server can only wait for all clients initiates a transfer or > time-out. A client can simply specify a time-out when doing an RPC to > handle stalling servers. I see. > 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. > >> 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- _______________________________________________ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
