Jonathan Robie wrote:
Steve Huston wrote:
I think we need a clean way to handle both binary and character data
in a streaming model. That's also very natural when
copying from files to messages.
True... The difficulty is that when you allow binary insertions
without the string intermedi
Steve Huston wrote:
I think we need a clean way to handle both binary and
character data in a streaming model. That's also very natural when
copying from files to messages.
True... The difficulty is that when you allow binary insertions
without the string intermediary, you need to provid
> -Original Message-
> Sent: Monday, April 27, 2009 11:20 AM
>
> Alan Conway wrote:
> > Jonathan Robie wrote:
> >> On the whole, I really like this. Comparing the example
> programs to
> >> the existing examples, I think it does simplify quite a bit.
> >>
> >> A few thoughts:
> >>
> >> 1
Alan Conway wrote:
Jonathan Robie wrote:
On the whole, I really like this. Comparing the example programs to
the existing examples, I think it does simplify quite a bit.
A few thoughts:
1. Streaming data into or out of messages
I really want to be able to stream into or out of messages direc
Jonathan Robie wrote:
On the whole, I really like this. Comparing the example programs to the
existing examples, I think it does simplify quite a bit.
A few thoughts:
1. Streaming data into or out of messages
I really want to be able to stream into or out of messages directly.
Instead of:
Jonathan Robie wrote:
On the whole, I really like this. Comparing the example programs to the
existing examples, I think it does simplify quite a bit.
A few thoughts:
1. Streaming data into or out of messages
I really want to be able to stream into or out of messages directly.
Instead of:
On the whole, I really like this. Comparing the example programs to the
existing examples, I think it does simplify quite a bit.
A few thoughts:
1. Streaming data into or out of messages
I really want to be able to stream into or out of messages directly.
Instead of:
message_data
James Mansion wrote:
Gordon Sim wrote:
Alan Conway wrote:
// Pull style:
LocalQueue lq;
queue.subscribe(lq);
while (...) { Message m = lq.get(); ... }
// Push style
MyListener l;
queue.subscribe(l);
sessoin.run();
}
How does any of this integrate into a single-
Gordon Sim wrote:
Alan Conway wrote:
// Pull style:
LocalQueue lq;
queue.subscribe(lq);
while (...) { Message m = lq.get(); ... }
// Push style
MyListener l;
queue.subscribe(l);
sessoin.run();
}
How does any of this integrate into a single-threaded application's
Alan Conway wrote:
Here is a simplified version of the proposal. It involves fewer classes
but I think is just as flexible and extensible as the original.
/**
This is a sketch of some highre-level patterns of use inte
Rafael Schloming wrote:
> (good stuff)
What he said, +1.
Unfortunately, as it were, if you want to go there, don't start from here.
Alan, Gordon:
How are you expecting flow of control to work wrt number of driver
threads and flow of control in any callbacks?
This is arguably a lot more imp
I like Rafi's idea.
As I have advocated before, the most compelling reason to make a C API
is the ability to support dynamic languages.
Given the popularity of dynamic languages this would be a very
important step in taking Qpid to the masses.
This approach would allow us to maintain several dynami
Alan Conway wrote:
Given the current state of affairs I'd say the following is the most
likely path to a C API:
1. Clean up, simplify and remove protocol-specifics from the C++ API.
Use handles to hide impls (in particular PIMPL the Message class) use a
single callback interface (MessageListe
Gordon Sim wrote:
Alan Conway wrote:
On Wed, 2009-04-15 at 15:37 +0100, Gordon Sim wrote:
I don't see view this work as replacing the existing API. I think it
is simply at a higher level of abstraction.
I see a role for a 'mid-level' API that provides full access to what the
protocol can d
Gordon Sim wrote:
James Mansion wrote:
Gordon Sim wrote:
James Mansion wrote:
My question is: why do you feel the need to create something
materially different, and why in particular does
a messaging API need to be much more complex for normal use?
Could you elaborate a little on what aspec
James Mansion wrote:
Gordon Sim wrote:
James Mansion wrote:
My question is: why do you feel the need to create something
materially different, and why in particular does
a messaging API need to be much more complex for normal use?
Could you elaborate a little on what aspect(s) you feel is/ar
Gordon Sim wrote:
James Mansion wrote:
My question is: why do you feel the need to create something
materially different, and why in particular does
a messaging API need to be much more complex for normal use?
Could you elaborate a little on what aspect(s) you feel is/are much
more complex?
Gordon Sim wrote:
There has been much discussion around the need for a higher-level c++
API that insulates an application from any protocol specific details
while allowing specific features of any given protocol to be exploited
through the abstractions and extension points that this API offers.
James Mansion wrote:
My question is: why do you feel the need to create something materially
different, and why in particular does
a messaging API need to be much more complex for normal use?
Could you elaborate a little on what aspect(s) you feel is/are much more
complex?
It won't be usab
Alan Conway wrote:
On Wed, 2009-04-15 at 15:37 +0100, Gordon Sim wrote:
I don't see view this work as replacing the existing API. I think it is
simply at a higher level of abstraction.
I see a role for a 'mid-level' API that provides full access to what the
protocol can do, without being ti
Gordon Sim wrote:
James Mansion wrote:
Sure you couldn't have a C API that is closely based on the MQSeries
one, with extra tweaks?
Or a C++ API that is much like the COM API from MSMQ?
Both with extensions as needed.
These are the most widely deployed existing systems. Sure you're not
goi
On Wed, 2009-04-15 at 15:37 +0100, Gordon Sim wrote:
> I don't see view this work as replacing the existing API. I think it is
> simply at a higher level of abstraction.
>
I see a role for a 'mid-level' API that provides full access to what the
protocol can do, without being tied to the protoco
Alan Conway wrote:
My first impression is that there are too many steps and too many
objects involved in sending/receiving messages.
Essentially there are 3 operations:
- send a message (to somewhere)
- pull a message (from somewhere)
- register a listener to have messages pushed (from somewhe
My first impression is that there are too many steps and too many
objects involved in sending/receiving messages.
Essentially there are 3 operations:
- send a message (to somewhere)
- pull a message (from somewhere)
- register a listener to have messages pushed (from somewhere)
We need to define
James Mansion wrote:
Sure you couldn't have a C API that is closely based on the MQSeries
one, with extra tweaks?
Or a C++ API that is much like the COM API from MSMQ?
Both with extensions as needed.
These are the most widely deployed existing systems. Sure you're not
going to design a bike
Carl Trieloff wrote:
One comment I would have. In AMQP 1.0 we will have Queues and links,
which can still handle the 0-10 model. However in an API would we not
want to drop the noun Exchange and just use BindTo() or LinkTo() so
that the API will work forwards to AMQP 1.0 with naming?
The noun E
Gordon,
One comment I would have. In AMQP 1.0 we will have Queues and links, which
can still handle the 0-10 model. However in an API would we not want to
drop the
noun Exchange and just use BindTo() or LinkTo() so that the API will
work forwards
to AMQP 1.0 with naming?
Carl.
Gordon Sim
Gordon Sim wrote:
All queries, comments, criticisms etc are very welcome.
Sure you couldn't have a C API that is closely based on the MQSeries
one, with extra tweaks?
Or a C++ API that is much like the COM API from MSMQ?
Both with extensions as needed.
These are the most widely deployed exis
Jonathan Robie wrote:
Aidan Skinner wrote:
On Tue, Apr 7, 2009 at 7:45 PM, Steve Huston
wrote:
I don't think trying a formal industry standard is adviseable, but
certainly trying to get some participation from other
AMQP-implementing bodies would be a positive step.
My view is debat
On Tue, Apr 7, 2009 at 7:45 PM, Steve Huston wrote:
> I don't think trying a formal industry standard is adviseable, but
> certainly trying to get some participation from other
> AMQP-implementing bodies would be a positive step.
+100
- Aidan (who thinks we should do more hugging with other
imp
Aidan Skinner wrote:
On Tue, Apr 7, 2009 at 7:45 PM, Steve Huston wrote:
I don't think trying a formal industry standard is adviseable, but
certainly trying to get some participation from other
AMQP-implementing bodies would be a positive step.
+100
- Aidan (who thinks we should do
> It would be really great if we could define this API as a
> standard and not just specific to apache/qpid. Is there
> anywhere this might live? Do others think that would be important?
I think that's very important, and there was some sentiment from
(potential) users expressed in favor of this
On Tue, Apr 7, 2009 at 6:39 PM, Gordon Sim wrote:
> William Henry wrote:
>>
>> It would be really great if we could define this API as a standard
>> and not just specific to apache/qpid. Is there anywhere this might
>> live? Do others think that would be important?
>
> Standardising is an arduous
William Henry wrote:
It would be really great if we could define this API as a standard
and not just specific to apache/qpid. Is there anywhere this might
live? Do others think that would be important?
Standardising is an arduous process. I think we should leave any thought
of that until user
Hi Gordon,
It would be really great if we could define this API as a standard and not just
specific to apache/qpid. Is there anywhere this might live? Do others think
that would be important?
William
- "Gordon Sim" wrote:
> There has been much discussion around the need for a higher-leve
35 matches
Mail list logo
