On 05/04/07, Tomas Restrepo <[EMAIL PROTECTED]> wrote:
One of the things that I've noticed is that the public interface the client exposes to the developer (at least the part that matters) is a bit messy at this moment. I think that we're running a bit late, but if we don't clean it up a bit now, down the road is going to be pretty hard to do once more people take a hard dependency on the current interface.
Yes, I would certainly agree we should improve now. The .NET client was literally thrown together as quickly as possible for a very particular, narrow use case. It certainly needs work to refine it.
It may not sound like a bit deal, but it's important in getting the library to look like it was written for .net in the first place.
Yes I agree this is very important.
I'm sure I'm missing more, but these would go a long way by themselves. It's also possible that maybe we need a more significant refactoring of the public interface in other to simplify it (or maybe a simpler api on top of it, I'm not sure yet).
I haven't used the .NET much nor am I a .NET developer but I all your points make sense to me.
Of course I'm aware some people (JPMC?) have applications built on top of the current API and changes like the ones I'm mentioning would affect them, but I thought I might as well throw it out there and see how people feel about it.
The use case in JPMC is unlikely to need to change for various reasons (even to track protocol changes) and even if it did there is an abstraction layer on top of the .NET client that isolates it further. So from that perspective we can feel free to make changes. I am potentially going to be a user of the .NET client in future due to the nature of the projects I am now working on and one question I have is this: should we be targetting WCF? Would a WCF implementation not speed our adoption in the .NET world? In the Java world we would have very few users if we did not support JMS. Is WCF not as important in .NET? RG
