o: dev@qpid.apache.org; cctriel...@redhat.com
Subject: Re: IKVMing the Java client for .Net
2009/1/23 Carl Trieloff :
> In a discussion with the Microsoft guys, I they where thinking of using the
> C++ client, with WCF on top of that. They seem to have thought about that
> quite a bit, s
On the Java broker side, we currently have no-one (unless I missed it)
declaring that they're working on 0-10 for M5. Is someone planning to
do this, firmly ? I think this has bearing on my (and other Java-ers)
views here of the short-term/medium-term requirements.
Marnie,
From the thread
I think a key point in our decision making here, one we have not always
given enough importance to, is the needs of our existing users. A few of
them bend my ear, so here goes
Qpid has been going for quite a while now, and we have many existing users
who have deployed a Java Broker and are us
Carl Trieloff wrote:
Aidan Skinner wrote:
On Mon, Feb 2, 2009 at 2:00 PM, Carl Trieloff
wrote:
Only supporting 0-10 means it won't talk to the current Java broker or
any of the other AMQP implementations such as OpenAMQ or RabbitMQ.
Does that really matter, we already have an 0-8 c
Aidan Skinner wrote:
On Mon, Feb 2, 2009 at 2:00 PM, Carl Trieloff wrote:
Only supporting 0-10 means it won't talk to the current Java broker or
any of the other AMQP implementations such as OpenAMQ or RabbitMQ.
Does that really matter, we already have an 0-8 client for .NET and ot
On Wed, Jan 28, 2009 at 8:01 PM, Robert Greig wrote:
> 2009/1/23 Aidan Skinner :
>
>> Traditionally, the approach to writing the .Net client has been to
>> transliterate the Java client by hand and slap a random API on top of
>> that. That seems like a bit of a waste of effort to me. I was thinki
On Mon, Feb 2, 2009 at 2:00 PM, Carl Trieloff wrote:
>> Only supporting 0-10 means it won't talk to the current Java broker or
>> any of the other AMQP implementations such as OpenAMQ or RabbitMQ.
>>
>
> Does that really matter, we already have an 0-8 client for .NET and others
> exist. We need t
Only supporting 0-10 means it won't talk to the current Java broker or
any of the other AMQP implementations such as OpenAMQ or RabbitMQ.
Does that really matter, we already have an 0-8 client for .NET and
others exist. We need to look
forward. I would say the target is Windows where dll's
On Fri, Jan 30, 2009 at 6:11 AM, David Ingham
wrote:
> Carl's right, we have been investigating the idea of layering a WCF channel
> implementation on top of the C++ client library. That is, the managed code
> channel implementation would pinvoke down to the native C++ code. This is the
> appr
I think if the C++ Broker on Windows becomes a truly first class citizen,
the WCF calling down to that would be fine and work very well.
Of course C++ can also be compiled to the CLR, but that would require the
C++ be quite extensively annotated for the purpose, so probably not a flyer.
IKVM is ve
2009/1/30 David Ingham :
> We're planning on putting in some effort in on this task but I think there
> are a few more pressing tasks on the Windows side of the house that we'll try
> to help out with first. Cliff has already commented on the build system
> issues; I think it'd be great if we c
t to be here and I look forward to working with you all.
Cheers,
Dave.
-Original Message-
From: Carl Trieloff [mailto:cctriel...@redhat.com]
Sent: Wednesday, January 28, 2009 12:25 PM
To: dev@qpid.apache.org
Subject: Re: IKVMing the Java client for .Net
Joshua Kramer wrote:
I tend to agree
iginal Message-
From: Carl Trieloff [mailto:cctriel...@redhat.com]
Sent: Wednesday, January 28, 2009 12:25 PM
To: dev@qpid.apache.org
Subject: Re: IKVMing the Java client for .Net
Joshua Kramer wrote:
>
>> I tend to agree that we'd need to build .NET stuff by hand on top
>> since in
Joshua Kramer wrote:
I tend to agree that we'd need to build .NET stuff by hand on top
since in a raw Java API there will be things that are not idiomatic in
.NET - e.g. no use of events, or capitalisation of method names etc.
Has anybody investigated the possibility of creating a .NET assemb
I tend to agree that we'd need to build .NET stuff by hand on top
since in a raw Java API there will be things that are not idiomatic in
.NET - e.g. no use of events, or capitalisation of method names etc.
Has anybody investigated the possibility of creating a .NET assembly from
the C++ clien
2009/1/23 Carl Trieloff :
> In a discussion with the Microsoft guys, I they where thinking of using the
> C++ client, with WCF on top of that. They seem to have thought about that
> quite a bit, so it would be good to get those comments onto the list also
> around this topic.
Is this not going to
2009/1/23 Aidan Skinner :
> Traditionally, the approach to writing the .Net client has been to
> transliterate the Java client by hand and slap a random API on top of
> that. That seems like a bit of a waste of effort to me. I was thinking
> about using IKVM to load the Java client as a library fo
Rafael Schloming wrote:
Aidan Skinner wrote:
I'm about to head off for a week, and thought I'd give this topic a
bit of a poke with a stick before I did so there's a bit of discussion
on the topic before we're deep into M5 territory.
Traditionally, the approach to writing the .Net client has b
Aidan Skinner wrote:
I'm about to head off for a week, and thought I'd give this topic a
bit of a poke with a stick before I did so there's a bit of discussion
on the topic before we're deep into M5 territory.
Traditionally, the approach to writing the .Net client has been to
transliterate the J
19 matches
Mail list logo
