Returning to the main topic of the thread. Here is a message by Gordon Sim
from the other thread:
In AMQP 0-10 there are two levels of acknowledgement. The first involves
accepting the message and your example code does that through the
_session.messageAccept(_range);
requests. Additionally
Rajith Attapattu wrote:
IMO it's not a very accurate picture.
Well, we can debate whether the assortment of protocol support levels
actually
has that affect, but its not really important.
Having said that, there would still be quite a bit of work maintaining
them and we would need an
Aidan Skinner wrote:
On Thu, Dec 3, 2009 at 10:11 PM, James Mansion
ja...@mansionfamily.plus.com wrote:
Aidan Skinner wrote:
It's particularly important where we're importing something which
duplicates (fully or partially) existing functionality, if only so
that the situation is sufficiently
A huge +1.
I mooted this idea a looong time ago :)
As mentioned at that time Apache Axis2/C project used this strategy to
successfully support web services APIs for a number of languages.
They had the core protocol engine written in C and then swig bindings
for c++, python, ruby, javascript, php
From the user perspective, we basically need a messaging solution, which is
a)robust b)have a nice dotnet client for Windows c)have a nice C++ client for
Linux.
I believe, this is the most common scenario imaginable. Everything else, like
Mono compliance or fanciness of WCF are somewhat
Hey Great work in committing the patches.
I see Julian had submitted another patch.
Thanks for coaxing him to work with Qpid again.
Looking at the volume of the patches it seems he cares about the C#
client quite a bit.
It would be great if you could persuade him to be the owner/maintainer
for
Aidan Skinner wrote:
On Thu, Dec 3, 2009 at 10:11 PM, James Mansion
ja...@mansionfamily.plus.com wrote:
Eh, I don't really want to get rid of the actively maintained clients
we already have. In particular, Java and C# derive enormous benefits
from purely managed code in terms of portability,
On Fri, Dec 4, 2009 at 4:18 PM, James Mansion
ja...@mansionfamily.plus.com wrote:
Aidan Skinner wrote:
On Thu, Dec 3, 2009 at 10:11 PM, James Mansion
ja...@mansionfamily.plus.com wrote:
Eh, I don't really want to get rid of the actively maintained clients
we already have. In particular,
Rafael Schlomingwrote:
To reiterate Aidan's point from a few emails ago, a quick look at JIRA
for the dotnet component[1] reveals a large number of patches that have
sat neglected for six months.
This is really shockingly bad and puts another spin on all the there is
no interest in
On Wed, Dec 2, 2009 at 12:13 AM, Carl Trieloff cctriel...@redhat.com wrote:
If there are a lot of devs/ users that want it that and put the effort in
to build such a thing and maintain it, for
example create a c++ shim for JMS for RDMA/IB. And a strong community forms
then why not?
I.e.
On Thu, Dec 3, 2009 at 3:36 PM, Aidan Skinner aidan.skin...@gmail.com wrote:
On Wed, Dec 2, 2009 at 12:13 AM, Carl Trieloff cctriel...@redhat.com wrote:
If there are a lot of devs/ users that want it that and put the effort in
to build such a thing and maintain it, for
example create a c++
Aidan Skinner wrote:
It's particularly important where we're importing something which
duplicates (fully or partially) existing functionality, if only so
that the situation is sufficiently clear to people trying to make an
informed decision about what best suits their needs.
Perhaps the QPID
On Thu, Dec 3, 2009 at 10:11 PM, James Mansion
ja...@mansionfamily.plus.com wrote:
Aidan Skinner wrote:
It's particularly important where we're importing something which
duplicates (fully or partially) existing functionality, if only so
that the situation is sufficiently clear to people
2009/12/2 Rafael Schloming rafa...@redhat.com:
If your goal is to deliver a robust .NET client on a single platform
in a short timeframe going down a non-managed hybrid route doesn't to
me appear unreasonable.
I don't think anyone has said that its an unreasonable approach if you only
care
2009/12/2 Aidan Skinner aidan.skin...@gmail.com:
Well, discounting myself (I have a half-baked^Wimplemented system to
manage my music using AMQP and Banshee), it's shipped in downstream
distros (eg. SLES10) and there was an effort to implement
System.Messaging for Mono on top of Qpid but that
On Wed, Dec 2, 2009 at 8:41 PM, Robert Greig robert.j.gr...@gmail.com wrote:
2009/12/2 Aidan Skinner aidan.skin...@gmail.com:
Well, discounting myself (I have a half-baked^Wimplemented system to
manage my music using AMQP and Banshee), it's shipped in downstream
distros (eg. SLES10) and there
2009/12/2 Aidan Skinner aidan.skin...@gmail.com:
But not enough demand for it to translate into any emails to our dev
lists asking for assistance (as far as I can recall).
Memories are fallible things. Search works much better. It's amazing
what you find.
I think you know perfectly well I
On Wed, Dec 2, 2009 at 11:00 PM, Robert Greig robert.j.gr...@gmail.com wrote:
2009/12/2 Aidan Skinner aidan.skin...@gmail.com:
But not enough demand for it to translate into any emails to our dev
lists asking for assistance (as far as I can recall).
Memories are fallible things. Search works
Robert Godfrey wrote:
2009/12/3 Aidan Skinner aidan.skin...@gmail.com
On Wed, Dec 2, 2009 at 11:00 PM, Robert Greig robert.j.gr...@gmail.com
wrote:
2009/12/2 Aidan Skinner aidan.skin...@gmail.com:
But not enough demand for it to translate into any emails to our dev
lists asking for
On Wed, Dec 2, 2009 at 6:21 PM, Rafael Schloming rafa...@redhat.com wrote:
Robert Godfrey wrote:
2009/12/3 Aidan Skinner aidan.skin...@gmail.com
On Wed, Dec 2, 2009 at 11:00 PM, Robert Greig robert.j.gr...@gmail.com
wrote:
2009/12/2 Aidan Skinner aidan.skin...@gmail.com:
But not enough
On Wed, Dec 2, 2009 at 6:35 PM, Rafael Schloming rafa...@redhat.com wrote:
Rajith Attapattu wrote:
The patches got neglected probably bcos we don't have an owner for the
.NET implementation.
Tomas who contributed the initial stuff and Arnaud who did the
subsequent stuff are no longer with
-Original Message-
From: Robert Greig [mailto:robert.j.gr...@gmail.com]
Sent: Monday, November 30, 2009 9:44 AM
To: dev@qpid.apache.org
Subject: Re: 1 msgs limit per session
2009/11/30 Rafael Schloming rafa...@redhat.com:
I'm not sure the stuff Cliff is working on (useful
Robert Greig wrote:
2009/11/30 Rafael Schloming rafa...@redhat.com:
I have no doubt that a suitably motivated individual could get this stuff
working on mono, and even make it production ready. The tricky part is
finding enough suitably motivated individuals to do this and to keep fixing
it
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
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.
2009/12/1 Robert Godfrey rob.j.godf...@gmail.com:
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
Robert Godfrey wrote:
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
Robert Greig wrote:
2009/12/1 Robert Godfrey rob.j.godf...@gmail.com:
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
On Tue, Dec 1, 2009 at 9:24 PM, Robert Greig robert.j.gr...@gmail.com wrote:
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
Robert Greig wrote:
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
Sounds like a bug, which version of .NET client are you using?
Carl.
Alexei Sosin wrote:
I noted that there is a limitation in .Net client, to receive 10 000 messages
only per session. Client just stops receiving them after this number has
passed.
Digging into the 0-10 client code, there
On 11/30/2009 06:14 AM, Alexei Sosin wrote:
I noted that there is a limitation in .Net client, to receive 10 000 messages
only per session. Client just stops receiving them after this number has
passed.
Digging into the 0-10 client code, there is a line in ClientSession.cs:
@qpid.apache.org
Cc: Cliff Jansen (Interop Systems Inc)
Subject: Re: 1 msgs limit per session
Sounds like a bug, which version of .NET client are you using?
Carl.
Alexei Sosin wrote:
I noted that there is a limitation in .Net client, to receive 10 000 messages
only per session. Client just
Systems Inc)
Subject: Re: 1 msgs limit per session
Sounds like a bug, which version of .NET client are you using?
Carl.
Alexei Sosin wrote:
I noted that there is a limitation in .Net client, to receive 10 000 messages
only per session. Client just stops receiving them after
Alan Conway wrote:
On 11/30/2009 06:14 AM, Alexei Sosin wrote:
I noted that there is a limitation in .Net client, to receive 10 000
messages only per session. Client just stops receiving them after
this number has passed.
Digging into the 0-10 client code, there is a line in
: 1 msgs limit per session
On 11/30/2009 06:14 AM, Alexei Sosin wrote:
I noted that there is a limitation in .Net client, to receive 10 000 messages
only per session. Client just stops receiving them after this number has
passed.
Digging into the 0-10 client code, there is a line
from.
From: Carl Trieloff [mailto:cctriel...@redhat.com]
Sent: Monday, November 30, 2009 4:12 PM
To: Alexei Sosin
Cc: dev@qpid.apache.org
Subject: Re: 1 msgs limit per session
The old 0-10 version that is pure .NET (0.5) or the updated version that Cliff
has been working extensively
Carl Trieloff wrote:
The old 0-10 version that is pure .NET (0.5) or the updated version that
Cliff has been working extensively on (coming in 0.6 from trunk)?
Sorry if this is confusing, we should deprecate the old one from the
source tree...
I'm not sure the stuff Cliff is working on
Aidan Skinner wrote:
On Mon, Nov 30, 2009 at 2:11 PM, Carl Trieloff cctriel...@redhat.com wrote:
The old 0-10 version that is pure .NET (0.5) or the updated version that
Cliff has been working extensively on (coming in 0.6 from trunk)?
Sorry if this is confusing, we should deprecate the old
Robert Greig wrote:
2009/11/30 Robert Godfrey rob.j.godf...@gmail.com:
I'm not sure how useful a metric this is as I would argue that none of our
.net clients have been completely production ready (as Rafi pointed out
earlier).
That must be a contender for the understatement of the month
2009/11/30 Rafael Schloming rafa...@redhat.com:
What I meant specifically was that you don't seem to have direct control
over creating, sending, receiving, or acknowledging messages. These would
seem to be something the framework does for you based off of a combination
of metadata and
2009/11/30 Rafael Schloming rafa...@redhat.com:
I have no doubt that a suitably motivated individual could get this stuff
working on mono, and even make it production ready. The tricky part is
finding enough suitably motivated individuals to do this and to keep fixing
it when it breaks. Given
2009/11/30 Robert Greig robert.j.gr...@gmail.com:
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
43 matches
Mail list logo
