Hi,
On Fri, Aug 24, 2007 at 02:14:38PM +0200, Carl Fredrik Hammar wrote:
> I'm not familiar with `kitten', and it didn't turn up in any of the
> searches I made. But I like its name :-), could you give me some
> pointers to where it's described?
I don't think it is described anywhere. Maybe it
Hi,
On Fri, Aug 24, 2007 at 02:14:38PM +0200, Carl Fredrik Hammar wrote:
> <[EMAIL PROTECTED]> writes:
> > On Wed, Aug 22, 2007 at 05:23:45PM +0200, Carl Fredrik Hammar wrote:
> >> But one might be able to use generic junctions if one layers a
> >> channel that makes sure all reads and writes are
Hi,
On Fri, Aug 24, 2007 at 02:14:38PM +0200, Carl Fredrik Hammar wrote:
> <[EMAIL PROTECTED]> writes:
> First a slight change in terminology, I will call an in-tee a
> `broadcast' and an out-tee simply a `tee'.
Well, for one, "broadcast" doesn't really fit here strictly speaking --
multicast se
mentation, 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
Hi,
<[EMAIL PROTECTED]> writes:
> Hi,
>
> On Wed, Aug 22, 2007 at 05:23:45PM +0200, Carl Fredrik Hammar wrote:
>> <[EMAIL PROTECTED]> 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
Hi,
On Wed, Aug 22, 2007 at 05:23:45PM +0200, Carl Fredrik Hammar wrote:
> <[EMAIL PROTECTED]> 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 h
Hello,
<[EMAIL PROTECTED]> writes:
> 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,
>> >>
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
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
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
Hello,
<[EMAIL PROTECTED]> writes:
> Well, I think we generally failed to define a clear terminology. Or
> maybe you actually did, and I only fail to stick to it. In any case, to
> make things clear, I'll explain what terms seem most logical to me. Let
> me know what you think of that. I have so f
Hi,
On Thu, Aug 02, 2007 at 04:57:36PM +0200, Carl Fredrik Hammar wrote:
> I was writing a reply to your message, trying to sort out this
> confusing subject, when it suddenly realized what the source of this
> confusion.
>
> I have considered channels to be a entity corresponding to a
> transla
Hello!
Carl Fredrik Hammar <[EMAIL PROTECTED]> writes:
> So in conclusion, a channel is a per-open entity, while a channel
> class is a per-server entity. When you layer channels you actually
> layer channel classes, how the actual channels get layered is
> class-specific. The class might open
Hello!
I was writing a reply to your message, trying to sort out this
confusing subject, when it suddenly realized what the source of this
confusion.
I have considered channels to be a entity corresponding to a
translator, a special translator that cleanly handles character device
semantics. Thi
Hi,
On Thu, Jul 26, 2007 at 09:24:32PM +0200, Carl Fredrik Hammar wrote:
> My solution is simple enough; they should all be implemented in
> channels (as opposed to being implemented in channelio.) This will be
> more general and give the user more control. The downside is that it
> will be a b
Hello,
after some careful thinking I think I have pretty good idea of how to
handle sessions, demuxing and buffering. My solution is simple
enough; they should all be implemented in channels (as opposed to
being implemented in channelio.) This will be more general and give
the user more control.
Hello,
<[EMAIL PROTECTED]> writes:
> Hi,
>
> On Sun, Jul 22, 2007 at 03:56:41PM +0200, Carl Fredrik Hammar wrote:
>
>> Having special channel classes (or perhaps some other type of modules)
>> for it seems like the right way to go. But the problem that these
>> channels can live in several transl
Hi,
On Sun, Jul 22, 2007 at 03:56:41PM +0200, Carl Fredrik Hammar wrote:
> Having special channel classes (or perhaps some other type of modules)
> for it seems like the right way to go. But the problem that these
> channels can live in several translators remain.
OK, let's look at an example:
<[EMAIL PROTECTED]> writes:
> Hi,
>
> On Thu, Jul 19, 2007 at 09:35:01PM +0200, Carl Fredrik Hammar wrote:
>
>> Suppose we want to record some audio which we may read from
>> /dev/sound/audio, which is a channelio translator. Additionaly we
>> want to broadcast the audio onto our internet radio st
Hi,
On Thu, Jul 19, 2007 at 09:35:01PM +0200, Carl Fredrik Hammar wrote:
> Suppose we want to record some audio which we may read from
> /dev/sound/audio, which is a channelio translator. Additionaly we
> want to broadcast the audio onto our internet radio station. These
> tasks are handled by
Hello!
I've thinking about use-cases for libchannel and started work on
channelio for the last few days and it got me thinking about sessions.
I found that I've been assuming that character devices are
session-less, mostly because they, unlike stores, are not seekable.
Now I'm not so sure that is
21 matches
Mail list logo
