[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Is beep really what operators would want?
>>>>> On Tue, 17 Jun 2003 10:29:02 -0700, Eliot Lear <firstname.lastname@example.org> said:
>> The beep protocol forces a fair amount of initial communication
>> upon the connection. This is a good thing from the management
>> application prospected, but bad from the cut-n-paste prospective.
Eliot> Think perl and it all makes sense ;-) If they can do it in perl
Eliot> without fancy encoding requirements then they can rapidly prototype
Eliot> new services and features.
Eliot> I would agree, by the way, that BEEP is probably 110% of what
Eliot> is needed in this space. I just don't think the other
Eliot> transports come close to 100%...
Don't read my statements wrong: I like the BEEP protocol and think
it has a lot of useful benefits that the netconf work can build on top
of. Of the transports discussed so far, its my favorite.
My question was that the *operators*, on the other hand, may be less
happy with it. They always gave me the impression that they wanted to
cut-and-paste into all the management protocols they were using. I
think that was an unreasonable constraint and I think both sides have
caved at this point toward a more reasonable middle ground. I'd even
suggest that BEEP is likely the best middle ground. I just wasn't
sure they'd reviewed the BEEP spec yet (since most of their time is
spent "operating" and not "reading"), so I was trying to cut out a few
useful extractions and concepts from the document.
"In the bathtub of history the truth is harder to hold than the soap,
and much more difficult to find." -- Terry Pratchett
to unsubscribe send a message to email@example.com with
the word 'unsubscribe' in a single line as the message text body.