Web-based Imaging Management Services: WIMS> FW: [Isms] BEEP

WIMS> FW: [Isms] BEEP as a transport for X

From: McDonald, Ira (imcdonald@sharplabs.com)
Date: Tue Aug 16 2005 - 13:47:34 EDT

  • Next message: McDonald, Ira: "WIMS> FW: Netconf: New Work: Asynchronous Notifications"

    Hi,

    Below are interesting comments from IETF people about why BEEP
    is nowhere near 'ready for prime time'. I pass these along (as
    Bert Wijnen did) because people should understand that there are
    NOT high quality libraries widely deployed for BEEP.

    For WIMS and other WS-protocols developed by the PWG, 'SOAP over
    something' (but not SOAP over BEEP) remains the best choice - that
    is, W3C SOAP/1.2. Developing anything new over non-interoperable
    SOAP/1.1 is a waste of time and money.

    Cheers,
    - Ira

    Ira McDonald (Musician / Software Architect)
    Blue Roof Music / High North Inc
    PO Box 221 Grand Marais, MI 49839
    phone: +1-906-494-2434
    email: imcdonald@sharplabs.com

    -----Original Message-----
    From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org]On
    Behalf Of Wijnen, Bert (Bert)
    Sent: Tuesday, August 16, 2005 10:38 AM
    To: isms@ietf.org
    Subject: [Isms] BEEP as a transport for X

    I saw some side conversations and polled for additional info.
    I got the following information on BEEP which I think will
    be good to know for this WG. Specifically, because (as far
    I have always understood the WG charter) the WG is trying
    to find a solution to allow SNMPv3 to be much better
    intergrated with (existing) operational security
    infrastructure.

    Bert
    -------------- fowarding with permission

    >From Andy Newton:
    >>
    >> The problem we faced in the CRISP working group is that BEEP
    >> was just too much for the simple request/response protocol
    >> we have developed.
    >> While there are new libraries now from both IBM and Apple
    >> which I have not had the chance to use, it seemed that most
    >> of the libraries we found were incomplete, out-and-out
    >> vaporware, or incredibly frustrating to understand from
    >> the API perspective.
    >>
    >> Now, if the question is "which is easier to implement,
    >> BEEP or SSH?" I'll bet that BEEP is the answer.
    >> But there are some pretty rock-solid implementations of
    >> SSH out there that surpass anything I have seen with BEEP.
    >>
    >> I like BEEP. I think it is a cool design. But the simple
    >> fact is that if your implementers want something easy to
    >> build or something easy to re-use, BEEP is not that (yet).
    >>
    >> -andy
    >>

    >From LEslie Daigle:

    >>>>> Subject: Arch....? Re: Notifications in LEMONADE
    >>>>>
    >>>>> So, BEEP is an interesting beast.
    >>>>>
    >>>>> *Architecturally*, it is the right direction. But, it is falling
    >>>>> down in reality because a) Marshall's attention moved on, and
    >>>>> b) the implementations are unwieldy. That is, if you don't
    >>>>> need all of the features of BEEP, finding your way into
    >>>>> the spottily-implemented and worse-documented libraries
    >>>>> is *ugly*.
    >>>>>
    >>>>> This, by the way, is why CRISP developed a non-BEEP tranport
    >>>>> for IRIS after the original BEEP one. And there have been
    >>>>> more implementations by key stakeholders *because* of that
    >>>>> change.
    >>>>>
    >>>>> Sigh. Sometimes the architecturally right thing gets undermined
    >>>>> by practical realities.
    >>>>>
    >>>>> Leslie.
    >>>>>

    _______________________________________________
    Isms mailing list
    Isms@lists.ietf.org
    https://www1.ietf.org/mailman/listinfo/isms



    This archive was generated by hypermail 2b29 : Tue Aug 16 2005 - 13:45:27 EDT