[Asterisk-Dev] WAS: click-to-call cleint NOW: XML Manager I/F str aw poll

[Daniel Grace]

On 1/17/06, Colin Anderson <ColinA at landmarkmasterbuilder.com> wrote:
> Disclaimer: Not trolling. Cross-posting to -users to gague support.
>
> -users : Straw poll - if an XML based Manager Interface was avaliable as an
> option in asterisk.conf, would that be a good thing, or a stupid thing?

In theory, if the internal manager interface were more structured I
would be 100% behind a method of having a small, light-weight way to
plug in a way to change the format of the messages. But given the
amount of code that would need to be changed and the questionable
benefits, I would much rather have the developers focused on more
important things.

> >Parsing XML requires a hell of a lot more weight than parsing the
> >current format.
>
> Yes and no. Depends who's parser you are talking about. The important thing
> to remember is that XML parsers are completely platform and language
> independent. One of Asterisks' true strengths is that it will plug into
> *everything* given enough prodding. An XML interface would facilitate that.
> If you chose a crap parser and performance sucked, that's your problem. Use
> another. There's lots. The point is, you would not have to reinvent the
> wheel every time you wanted to I/F something to Asterisk. How hard would it
> be to turn the Manager into an RSS feed if XML were an option? (stupid
> example but you get my idea)

Parsing XML is necessarily more expensive in both bandwidth and clock
cycles. Not to mention all the ways that the format can be potentially
broken by bad input from sources that asterisk doesn't control. You
have to HTML-escape virtually anything that comes in for fear of
outputting invalid XML.

The format has its advantages, some of which would come in handy with
the manager. However, claiming that it's not necessarily slower than
current parsers is just plain wrong. If I only care about a single
field, my quick and easy path to parse it is quite simple: look for
the field name followed by a colon. The monent a single letter doesn't
match, I can throw away the entire line.

Now put it in XML. Suddenly I have to deal with whitespace not
"meaning" anything, and a whole slew of < and > thrown in there. Just
the fact that whitespace doesn't mean anything immediately means that
you have to look at every character in order to find the beginning of
a tag. The language or library you're using may hide this from you,
but it's doing it behind the scenes, which adds up to processor
cycles.

I've been known to propose XML when it makes sense. I'm going to side
with the 'no' side on this case though.

> >Tell you the honest truth, I just don't like XML.  Waste of bits.
>
> I've read posts from OEJ (I think) along the same lines - he's an XML
> proponent, and Mark is not. He (Mark) feels it's too fat. I'm sure that the
> majority of the guys on -dev hate XML as well. However, XML is not going
> away anytime soon - aw hell, it's here to stay, forever. So, might as well
> hold your nose, and support it. My gut tells me if you took a straw poll on
> -users, an XML implementation would recieve overwhelming acceptance. This is
> something that *users* want. You know, the guys that *use* Asterisk. It
> would also open the door wide open for all sorts of crazy, interesting,
> unique, and cool implementations. And that's what Asterisk is all about.

XML isn't going away because for the right cases it makes sense. It is
not the end-all bullet that everything must support or die though.
There is no reason that you can't do crazy, interesting, unique, and
cool things with the current manager interface. It's what I do for
employment.

As a relative newcomer I'll relay another reason to keep the current
interface. It looks like HTTP headers. It looks like SIP headers. It
looks like ... well, a lot of things. It's easy to read and for anyone
that's been around, it's familiar. You immediately know what things
mean. Of course these aren't arguments against supporting _both_...
but see one of my first statements. There are more important things.

Daniel