[BXXPwg] Draft Minutes of last week's meeting

Steve Harris sharris@primus.com
09 Aug 2000 23:22:01 -0700

"Marshall Rose" <mrose+mtr.netnews@dbc.mtview.ca.us> writes:

> i think there are at least 5 existence proofs of code written by different
> people that nested XML isn't a problem. so i think you are proceeding from a
> false premise.

Can you share a summary of the interfaces these projects use to start
up a channel? In particular, I'd like to see the arguments to however
a "session" opens a new "channel."

As an act of good faith, I'll share some of my initial *sketch*
code. Please don't judge it or even try to compile it; it's just me
thinking in syntax.
[It's C++.]
class profile_factory
    virtual ~profile_factory();

    // !!! We'll also have to push in the descendent element content
    // of a <profile> element.
    virtual std::auto_ptr<profile_handler>
            create(const char* pcszProfileName,
                   size_t nLen) = 0;

class channel
    // create messages

    std::auto_ptr<profile_handler> m_phandler;

class session : noncopyable
    session(/* socket */, profile_factory& factory);

    channel& open_channel(const std::set<const char*>& setProfiles,
                          const char* pcszServerName);

    // socket
    profile_factory& m_factory; // supported profiles - for incoming requests

    static const size_t cnMaxChannels = 256;
    std::auto_ptr<channel> m_channels[cnMaxChannels];

Look at the BXXP::session::open_channel method. From reading the
spec., it looks like you need a way to offer up a set of potential
profiles (arguably, perhaps, they should be an ordered sequence to
indicate priority) for the peer to choose from, as well as an optional
"server name." The returned reference to a channel would hide the
allocated channel number; I'd like to hide that from an
application. Since the channel lifetimes are managed by the session,
we can return the channel by reference.

But look at what's missing. How does the caller know _which_ profile
was selected? Should we return a std::pair<channel, const char*> (or
however else you choose to represent a profile) to indicate, "Here's
your channel, and here's what profile you're talking on?" Again, it
seems to make more sense "on the wire" than from the point of view of
an application.

Also, I've omitted a way for the application to pass in any content of
a <start>/<profile> element. If I take a brain-dead approach and just
take a text buffer as the <start>/<profile> content, then my input
arguments must be something more like a const std::map<const char*,
const char*>& (or perhaps std::string...) where the second string is
the <start>/<profile> content for each profile. Assuming that there
_is_ content to be sent inside the <profile> elements, that looks like
a lot of preparation for the application to go through.

It looks clearer from the interface point of view to only offer to
start a channel with a single profile, and fail if that profile is not
supported. Then the application would try another profile. It would
also be clearer which profile had been accepted. Unfortunately, that
defeats the efficiency of being able to ask for one of several
profiles all at the same time.

Marshall, it's clear to me that it's not that hard to compose the
framing and XML messages at the low level to, say, open a channel. But
I am claiming that it's hard to wrap these semantics up in a way that
makes for an appealing API - and I see that as a risk.

I keep harping on the "start a channel" scenario because it's so
unnatural from the the point of view of a typical programming language
function. It reads like, "Here's a whole bunch of choices, and maybe
some data with each choice, so go see if you can start one of these
and, if so, give me some handle back so I can talk on that
channel. Oh, yeah, and let me know which one of my choices got
accepted, or if none of them did."

Another possible way to solve that is to give a handle back, then let
the caller figure out from the handle which profile it's talking. That
also strikes me as a highly unnatural call sequence.

I would very much like to see BXXP succeed, and help it to succeed, so
don't think I'm trying to derail anything here. Maybe it will take
more collective thought to get this right, or just to help me see the
solution I'm missing. Any examples or ideas are welcome.

Steven E. Harris        :: sharris   @primus.com
Primus                  :: http://www.primus.com