[BXXPwg] <!ELEMENT profile ANY>

Sarveshwar Rao Duddu duddu@vsnl.com
Tue, 18 Jul 2000 21:57:17 +0530

> [...]
> Just a side note here regarding the content of the start/profile
> element - it makes formulating an API *extremely* difficult! When an
> application wants to ask for channel creation, it may optionally
> provide, in addition to a set of profiles, *arbitrary XML content*
> within each profile. Feeding this content in on the initiator side,
> and feeding it to the application on the listener side, is very
> tricky.

    There is another problem. becuase the response to start message may return

    data of any length, the application has to come in picture and read that
    Channel 0 (meaning the beep implementation) should not allocate memory for
    The application will have to read it. The beep implementation is not
bothered what
    is there in it.

> On the receiving end, you can demand that the acceptor implement the
> common set of SAX-style event-based call-backs to receive the content
> of the profile element. On the initiator side, though, how would you
> do it? Take a character buffer to some XML content? The application
> may feed in non-well-formed content, which would be stupid to
> permit. Take a node tree fragment? That requires implementing a grove
> or DOM-style node facility. That seems like overkill. Allow the
> initiator to call event-based call-backs to create the XML content? The
> call sequence gets weird.

    My idea is that the application passes a string which is parsed and
checked before it
    is sent.

> This whole content-of-the-profile-element issue is turning out to be
> one of the most difficult problems in crafting an API. What would be
> so wrong about forcing this content to be in a separate
> application-specific message, basically becoming the content of the
> first message on the newly-created channel? It would unify the
> treatment of application-provided data v. data handled by BXXP's
> channel 0.

    This solves the above problem. After channel creation, as any other
request or response,
    the start element is sent on it, and as in all other cases, the
application is responsible for
    reading the response from buffer. This will make it more uniform. And i
thinks it is a great idea.

> Please don't dismiss this problem without thinking these points
> through.
> --
> Steven E. Harris
> Primus Knowledge Solutions, Inc.
> http://www.primus.com