RE: Channel response serialization

> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]]On Behalf Of Jered Floyd
> Sent: Wednesday, July 24, 2002 6:51 PM
> To: Paul Andrews
> Cc: [email protected]
> Subject: Re: [BEEPwg] Channel response serialization
>
>
>
> > I ask because it seems that this excludes a large class of
> > applications from using BEEP, so that those of us who need truly
> > asynchronous messaging are left with the same problem that BEEP was
> > intended to solve. Namely: HTTP doesn't quite fit and SMTP doesn't
> > quite fit.
>
> In what situations is the opening of multiple channels insufficient
> for your purposes?

It isn't insufficient in itself, but it prevents me from attaching a
semantic purpose to the channel number (all of the requests have the same
semantic here, just a different payload). It also means that I have to
implement yet-another-pool-mechanism to manage the allocation of channels in
a manner invisible to the application.

It struck me that that wasn't really the purpose of channels. I got the
impression that channels were intended to have a semantic purpose - and
that's how I would like to use them, e.g. channel 0 is a control channel -
you wouldn't allocate multiple control channels arbitrarily to get around
the serialization restriction otherwise how would BEEP know that they were
control messages?

Finally the restriction on reply ordering seems to be arbitrary and forces
people like me to put in a lot of extra work that we wouldn't have to do if
the restriction wasn't there (I know, we all want something for nothing
:-) ).

>
> --Jered
>
> _______________________________________________
> BEEPwg mailing list
> [email protected]
> http://lists.beepcore.org/mailman/listinfo/beepwg