2009/12/1 Robert Greig <robert.j.gr...@gmail.com> > 2009/12/1 Rafael Schloming <rafa...@redhat.com>: > > > I think the point for this thread is that if it is windows-only then it > > isn't really a substitute for the existing dotnet clients which work (in > as > > much as they have ever worked) on mono. > > Well that assumes that running on mono is a goal? Do we have any users > of the .NET client on Mono? > > IKVM is a way of running Java. I have no idea whether IKVM implements > enough of the JDK libraries to enable the Qpid Java client to run > under it but let's assume for the moment that it does. Further, let us > assume that some important change in 0.6 or another upcoming release > breaks that. Do we say that we should not proceed with that change > because IKVM isn't supported? > > Not quite the same thing is it? A better analogy might be to imagine that the JMS client required the use of the compiled C++ libraries and say we only supported Java on Windows and Linux... I think that to have implemented the JMS client in that way would have been a poor choice.
> I think it (fairly obviously) depends on the demands of our users (and > our perceptions of those demands). How many people want a .NET client > that doesn't work on any platform versus a WCF platform that works on > Windows? > > These goals shouldn't be contradictory. > > So the question in both cases is whether or not there is a good reason > for > > the code (both the WCF impl and the C++ broker) to be platform specific. > > I can see that it would be nice to have a completely managed code .NET > library (for example, I think you need to be fully managed to support > one click deployment?). However I can also see that leveraging the > existing C++ codebase is very attractive since the core of it has been > tested a lot on linux and the port of the rest is required for a > Windows broker. > > If I was doing this work, that may well be the way I attempted to first implement the WCF client also; and I'm in no way arguing that this code shouldn't form part of the Qpid project. I think a fully managed solution would be superior however, and would also have the not inconsiderable advantage that it (and its tests) could be more easily run by the great number of Qpid developers who do not use Windows as their operating system. > It would be interesting to know if this is why the Microsoft guys > decided to take that approach rather than rewriting the managed code > client. > > Agreed. Going back to an earlier part of this thread, Rafi and you had the following exchange: > > I can see how you might be able to accomplish some of the same sorts of > > things as a messaging API in this way, however I'm somewhat skeptical that > > the result would be equivalent to a complete messaging API, or that we'd end > > up with something that would appeal to our users. > I think this is a good point. In my opinion MSFT didn't do a great job > of System.Messaging when they first did it (i.e. long before WCF) > because it was very tightly coupled to MSMQ so there isn't really a > decent non-implementation-specific messaging API in .NET. WCF does I > think attempt to address that in a very generic way - but maybe it is > too generic to be useful for people who do want a low-level messaging > API. > > Even if it would work, this approach seems somewhat inside out. Why not have > > a dotnet messaging API and build out a WCF transport on top of that rather > > than having a private messaging API that is internal to the WCF messaging > > implementation which is then reexposed via special service contracts. > This is what IBM have done - they have a messaging API that is not > unlike JMS and on top of that they have built their WCF channel which > is specifically aimed at providing SOAP over MQ. I think the above (building WCF on top of a lower level messaging API) should be our goal. And further we should attempt to make that lower level API as independent as possible of particular AMQP versions (given the upcoming release - hopefully - of AMQP v1.0). My understanding is that Gordon, Rafi and others have been working hard on defining an abstract messaging API not bound to a particular version of AMQP but informed by AMQPs capabilities. Further that the C++ and Python clients will be implementing this API so that each of these clients will implement a common API (obvious language differences aside). I do not think it an unreasonable goal that we implement such a common low-level API across all our clients; and build things such as JMS and WCF on top of those (expecting that 90% of the user population in those languages would use the WCF or JMS api). Having such a common low level API would also, one hopes, make it easier to transfer from a non-managed code underlying library to a managed code library for .net. Cheers, Rob
