But hold on. We already agree that such an API should look 1:1 like the protocol. Its not as if the API, even if implemented as a blind-fold experiment, by different groups with no contact, in different languages, is going to look radically different. The protocol XML itself is already the language neutral spec.
BTW. I think MS has seen the light on functional languages, faster than most. On 23/08/07, Michael Arnoldus <[EMAIL PROTECTED]> wrote: > > Den 23/08/2007 kl. 11.27 skrev Robert Greig: > > > On 23/08/07, Rupert Smith <[EMAIL PROTECTED]> wrote: > > > >> One thing that seems to have come up a few times, is the idea that > >> it would > >> be hard to have the same API across different languages. I don't > >> think it > >> would be technically hard to do this. > > > > Yes, plus it's practically hard given other factors involved. Even OO > > languages have different conventions - witness the rather clunky > > result of transliterating the Java client into .NET. > > > > To my mind, having idiomatic clients in each language is going to > > result in a far better experience for those developers. > > > > RG > > I agree - and again agree totally!!! > > As an open source thing I would expect the primary adoption of AMQP > to come from the developers doing the work. They will choose to use > AMQP if they get something they feel take care of their requirements > and is easy to start using. Some API that might be standard in some > OO specific way might look ridiculous in another language than the > one providing the original design perspective - and the resistance to > adoption will increase - or somebdy working in another language will > write their own API on top of the standardized one and everybody will > use that - in which case we end up the same place. > > And BTW - I strongly oppose the OO is everything view put forward in > the previous suggestion. Even MS has started to see the light :-) > > Check out http://blogs.msdn.com/charlie/archive/2007/01/26/anders- > hejlsberg-on-linq-and-functional-programming.aspx > > Michael Arnoldus > >
