Gordon Sim wrote:
On 09/15/2009 10:42 PM, Andrew Wright wrote:
The main need we've run across for a lower level java api comes from
performing administrative functions from code - a standardised admin api
would certainly be useful (cf. MQSeries PCF). I'm not sure there would
be much benefit from
On 09/15/2009 10:42 PM, Andrew Wright wrote:
The main need we've run across for a lower level java api comes from
performing administrative functions from code - a standardised admin api
would certainly be useful (cf. MQSeries PCF). I'm not sure there would
be much benefit from shoehorning this i
On 15 Sep 2009, at 21:57, James Mansion wrote:
Jonathan Robie wrote:
In the languages besides Java, there is no standard messaging API
to fall behind. I'll say something more on Java in a separate
message.
If its market share of deployed MOM components that lie strangely
unused, its MSMQ.
Jonathan Robie wrote:
In the languages besides Java, there is no standard messaging API to
fall behind. I'll say something more on Java in a separate message.
If its market share of deployed MOM components that lie strangely
unused, its MSMQ.
If market share of paid-for MOM matters, isn't MQSe
Bill Whiting wrote:
I think it would be more worthwhile to try to synchronize the APIs
between the languages.
i.e. make the python/C++ APIs look more alike. Obviously there are
language differences, so they won't be identical. I think it would be
beneficial if you could expect that the class
I think it would be more worthwhile to try to synchronize the APIs
between the languages.
i.e. make the python/C++ APIs look more alike. Obviously there are
language differences, so they won't be identical. I think it would be
beneficial if you could expect that the class structure would be s
Jonathan Robie wrote:
Do we want the new messaging API to be useful for other messaging
systems that are not based on AMQP, or is that a non-goal?
So far the primary goal has been to be useful to applications, which
means the API inevitably includes support for functionality that isn't
necess
Do we want the new messaging API to be useful for other messaging
systems that are not based on AMQP, or is that a non-goal?
Jonathan
-
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Intera
Jonathan Robie wrote:
That's how the examples in other languages work - there is a separate
program that sets up the configuration, a publisher that sends messages,
and a consumer that reads messages from a queue.
Private queues (exclusive + autodelete) are treated differently, the
client con
Rafi,
Below is the link for a proposal that you helped me put together.
http://cwiki.apache.org/confluence/display/qpid/Proposal+for+a+new+JMS+Destination+configuration2
I think it captures most of the concepts you have talked about in this thread.
Perhaps we could use that as a basis for a propo
Rafael Schloming wrote:
Jonathan Robie wrote:
Rafael Schloming wrote:
There really are two separate configuration topics here:
configuration of the client (which is reasonable to do via JNDI) and
configuration of the broker (which nobody in their right mind would
ever consider doing via JNDI)
Jonathan Robie wrote:
Rafael Schloming wrote:
There really are two separate configuration topics here: configuration
of the client (which is reasonable to do via JNDI) and configuration
of the broker (which nobody in their right mind would ever consider
doing via JNDI). It would probably be he
2009/9/14 Jonathan Robie :
> Martin Ritchie wrote:
>>
>> Have you thought how the configuration can still be performed via JNDI?
>>
>> I have mentioned this before on the list so will be brief (well that
>> was the aim). I really don't see any advantage to adding new a API (of
>> any sort) on the j
Rafael Schloming wrote:
There really are two separate configuration topics here: configuration
of the client (which is reasonable to do via JNDI) and configuration
of the broker (which nobody in their right mind would ever consider
doing via JNDI). It would probably be helpful clarify which one
On Mon, Sep 14, 2009 at 3:11 PM, Jonathan Robie
wrote:
> Rafael Schloming wrote:
>>
>> FWIW, the way gsim and I have discussed dealing with configuration is to
>> provide a reasonable text based syntax for specifying an address/destination
>> that is just a name plus additional sender/producer or
Rafael Schloming wrote:
FWIW, the way gsim and I have discussed dealing with configuration is
to provide a reasonable text based syntax for specifying an
address/destination that is just a name plus additional
sender/producer or consumer/receiver options. This should permit some
consistency in
Jonathan Robie wrote:
Martin Ritchie wrote:
Have you thought how the configuration can still be performed via JNDI?
I have mentioned this before on the list so will be brief (well that
was the aim). I really don't see any advantage to adding new a API (of
any sort) on the java side. Allowing 10
Martin Ritchie wrote:
Have you thought how the configuration can still be performed via JNDI?
I have mentioned this before on the list so will be brief (well that
was the aim). I really don't see any advantage to adding new a API (of
any sort) on the java side. Allowing 100% compliant JMS code t
Jonathan Robie wrote:
Martin Ritchie wrote:
Are you suggesting writting a new Configuration API for the Java client?
No - Java JMS is the high level API for the Java client. Note that one
of the possible directions I suggested is to provide a way for other
languages to support the Java JM
Martin Ritchie wrote:
Are you suggesting writting a new Configuration API for the Java client?
No - Java JMS is the high level API for the Java client. Note that one
of the possible directions I suggested is to provide a way for other
languages to support the Java JMS properties files. The
Martin Ritchie wrote:
Jonathan,
Are you suggesting writting a new Configuration API for the Java client?
Have you thought how the configuration can still be performed via JNDI?
I have mentioned this before on the list so will be brief (well that
was the aim). I really don't see any advantage t
Martin Ritchie wrote:
Jonathan,
Are you suggesting writting a new Configuration API for the Java client?
Have you thought how the configuration can still be performed via JNDI?
If I'm not mistaken, Jonathan was referring to the emerging C++ and
Python messaging APIs, not the Java APIs.
-T
On Mon, Sep 14, 2009 at 11:31 AM, Martin Ritchie wrote:
> Are you suggesting writting a new Configuration API for the Java client?
>
> Have you thought how the configuration can still be performed via JNDI?
I think it's important that we offer both. Being able to do this via
configuration is nea
Jonathan,
Are you suggesting writting a new Configuration API for the Java client?
Have you thought how the configuration can still be performed via JNDI?
I have mentioned this before on the list so will be brief (well that
was the aim). I really don't see any advantage to adding new a API (of
a
Rafael Schloming wrote:
Rafael Schloming wrote:
The upshot is you can sort of look at these as providing a JMS-like
API plus some critically missing bits minus some extra cruft.
One thing I should say before someone accuses me of bashing our JMS
client too much is that most of the criticall
Rafael Schloming wrote:
Jonathan Robie wrote:
In another message, I suggest separating out the configuration API
from the messaging API.
In this message, I wonder whether we should consider using either AMQP
1.0 or Java JMS as the model for the new messaging API, rather than
create a third m
Jonathan Robie wrote:
In another message, I suggest separating out the configuration API from
the messaging API.
In this message, I wonder whether we should consider using either AMQP
1.0 or Java JMS as the model for the new messaging API, rather than
create a third model that nevertheless ne
In another message, I suggest separating out the configuration API from
the messaging API.
In this message, I wonder whether we should consider using either AMQP
1.0 or Java JMS as the model for the new messaging API, rather than
create a third model that nevertheless needs to bridge both Java
28 matches
Mail list logo
