RE: Channel response serialization

> -----Original Message-----
> From: Jered Floyd [mailto:[email protected]]
> Sent: Thursday, July 25, 2002 3:25 PM
> To: Paul Andrews
> Cc: [email protected]
> Subject: Re: [BEEPwg] Channel response serialization
>
>
> "Paul Andrews" <[email protected]> writes:
>
> > But I like shooting myself in the foot! I guess the point is that
> > serialization is something that can be layered on top of
> parallelism, but
> > not vice-versa. At least when operating within the constraints
> if a single
> > framework.
>
> Metatarsal ballistics aside, while we can implement serialization on
> top of a parallel layer, we can't implement pipelining on top of a
> parallel layer (because we have to wait for the response to arrive on
> a channel before we know we can send the next request and have it be
> processed in order.)...

Weeeelllll. If I understand correctly (a big if at this point). You still
don't have that guarantee because all you are specifying is that replies
have to be sent in the same order that requests are received. Nothing is
stated about the order in which requests have to be processed. In fact to
paraphrase an earlier reponse in this thread: the library actually holds
responses until all repsonses to eariler requests have been sent. This
implicitly allows you to give responses to the library out-of-order.

> ... I think one of the purposes of the channel
> abstraction is to explicitly allow for both the intra-channel
> asynchorony of pipelining and the inter-channel asynchrony of
> parallelism.  I'd rather not see pipelining go away in favor of
> intra-channel parallelism... I don't think it's called for.

It would be nice to be able to negotiate the exact level of synchronicity
(synchronousnous?) required on a single channel.  i.e.:

- Totally asynchronous.
- Synchronous responses.
- Synchronous requests and synchronous responses.

In fact I think Marshall has pointed out that that is a possibility using
'features'.

This would not obviate the need for channels, it would just free them up to
be used at a purely application semantic level rather than a mix of
application and protocol semantic levels.

>
> (I won't address your web browser example here, as I think Darren and
> Marshall did a good job of that.)
>
> > > If you think it would be interesting to explore, I believe it would be
> > > relatively easy to modify PermaBEEP to remove both this and the
> > > restriction on reply ordering.  I'm not sure there's a lot of value in
> > > it, though.  (Hm, and I really must roll the 0.9 release soon; I meant
> > > to do that last month.)
> >
> > Interesting point. I guess I tend to think that standards are written in
> > stone. I could act unilaterally to remove the serialization
> requirement but
> > I guess I need to convince myself that I'm not talking rubbish
> and I would
> > also prefer to work within the standards process if at all possible.
>
> I'd be happy to point you at the right parts of the code if you'd like
> to explore this further, but I really do think that channel pools are
> the right way to go about doing this.  But perhaps I'm old and set in
> my ways. *grin*

LOL. Bet you're not as old as me.

Anyway, yes you can point me at the right parts of code. I'm a Java
programmer by preference. Of course, I might come to the same conclusions as
y'all.

By the way, why isn't PermaBEEP listed at beepcore.org?


>
> --Jered
>