![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
>> Frankly, I don't see what the "abstraction of the transport >> layer" provides you. It means you don't have to define the same things again and again. SOAP is important, but there are many others types of messaging - http://www.ietf.org/internet-drafts/draft-ietf-apex-core-05.txt http://www.ietf.org/internet-drafts/draft-new-webi-wcip-beep-00.txt http://www.ietf.org/internet-drafts/draft-ietf-idwg-beep-idxp-02.txt http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-beep-00.txt http://www.ietf.org/internet-drafts/draft-ietf-sacred-protocol-beep-pdm- 00.txt http://www.ietf.org/internet-drafts/draft-ietf-syslog-reliable-12.txt Are we expected to duplicate and define slightly different variations of the 50 pages of the BEEP spec inside each of these? And repeat roughly every 6-8 weeks when the IETF and others start work on a new type of messaging (e.g. http://www.ietf.org/html.charters/provreg-charter.html). Rather than concentrating solely on SOAP, we have to consider the wider picture, and come up with an appropriate solution - in this scenario I think using BEEP is very sensible. Other people have differing views - that is fine. Diversity is good! >> I personally find BEEP quite atrocious. It introduces a "channel" >> artifact that is gratuitous complexity; it breaks at least one >>fundamental rule of networking, by allowing for multiplexing on >>top of TCP. On the issue of whether BEEP itself is a good idea or not based on these questions, see: http://lists.beepcore.org/pipermail/beepwg/2001-July/001210.html On the issue of "gratuitous complexity": I can tell you in practical terms it is roughly 50 lines of C# code. For those people who - after carefully examining the alternatives for richer messaging (e.g. http://www.clipcode.com/peer/http_async_notif.htm) - think BEEP is a good thing, and now wish to use it to carry SOAP messages - is there anything technically wrong with, or do you have any suggestions for improvements to, the SOAP over BEEP spec as proposed? Eamon
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.