Re: C# client for 0-10?

[Carl Trieloff <cc...@redhat.com>]

Robert Greig wrote:
> 2008/11/27 Aidan Skinner <ai...@apache.org>:
>
>   
>> That's a good question. Mono on windows is... doable, but a bit
>> perverse still...
>>     
>
> Yes, if we want to do mono, fine but we absolutely must make sure it's
> all seamless with Microsoft .NET versions. I hope it's been tested
> with MS .NET? After all, most of our users will be using Microsoft
> runtimes.
>
> RG
>   

The build works on both mono and native. I expect that all that is 
needed is are minor
updated to have it build on 2.0 and 3.5. I had assumed build on 2.0 and 
then run on anything.

Is there any advantage building on a later version?

Maybe one of the Mircosoft guys want to give us some best practices on this

Carl.

Re: C# API boilerplate

[Robert Godfrey <ro...@gmail.com>]

2008/12/4 Aidan Skinner <ai...@apache.org>:
> On Thu, Dec 4, 2008 at 1:24 AM, Robert Godfrey <ro...@gmail.com> wrote:
>
>> Given the changes that are likely coming int he AMQP1-0 protocol I
>> would (with my Qpid hat on) strongly recommend that we try to
>> implement some kind of common abstraction that could be applied on top
>> of the existing API.
>
> System.Messaging perhaps?
>

That certainly sounds like a sensible idea :-)

-- Rob

Re: C# API boilerplate

[Aidan Skinner <ai...@apache.org>]

On Thu, Dec 4, 2008 at 1:24 AM, Robert Godfrey <ro...@gmail.com> wrote:

> Given the changes that are likely coming int he AMQP1-0 protocol I
> would (with my Qpid hat on) strongly recommend that we try to
> implement some kind of common abstraction that could be applied on top
> of the existing API.

System.Messaging perhaps?

- Aidan
-- 
Apache Qpid - World Domination through Advanced Message Queueing
http://cwiki.apache.org/qpid
"Have we anything resembling a plan?" "Mm-hm. Ride till we find
them... and kill them all." - The 13th Warrior

Re: C# API boilerplate

[Robert Godfrey <ro...@gmail.com>]

>> I realize some of the complexity exists because AMQP provides many
>> features...perhaps qpid can provide a stupidly simple, default, way of
>> getting at the data within a few lines?
>
> It is certainly the job of the API to hide any complexity in the protocol.
>
> RG
>

Given the changes that are likely coming int he AMQP1-0 protocol I
would (with my Qpid hat on) strongly recommend that we try to
implement some kind of common abstraction that could be applied on top
of the existing API.

-- Rob

Re: C# API boilerplate

[Robert Greig <ro...@gmail.com>]

2008/12/2 Shahbaz Chaudhary <sc...@marcopolonetwork.com>:

> Instead the example contains binary readers, bytes, encodings, etc.:
>
> BinaryReader reader = new BinaryReader(m.Body, Encoding.UTF8);
> byte[] body = new byte[m.Body.Length - m.Body.Position];
> reader.Read(body, 0, body.Length);
> ASCIIEncoding enc = new ASCIIEncoding();

I agree, I had not looked at this before but it does seem particularly
cumbersome to use.

> -----
> The code to create connection and session also looks unnecessarily
> noisy.  I have to provide the queue name to the ClientSession object
> three times (twice in one method call):
>
> ssn.queueDeclare("queue1", null, null);
> ssn.exchangeBind("queue1", "amq.direct", "queue1", null);
> sn.messageSubscribe("queue1", "myDest", MessageAcceptMode.EXPLICIT,
> MessageAcquireMode.PRE_ACQUIRED, null,0, null);

Agree again, this could be improved.

> The call-back method in IMessageListener is called messageTransfer(),
> isn't it better to simply call it onMessage()?

I suspect this is the protocol leaking into the API?

> I think it will be a good idea to expose incoming message as
> Events...since that's what incoming messages are and the semantics of
> qpid subscribed messages and the Events feature match perfectly.

It does break down a bit when you're using a synchronous GET mode
(rather than a message listener).

> I realize some of the complexity exists because AMQP provides many
> features...perhaps qpid can provide a stupidly simple, default, way of
> getting at the data within a few lines?

It is certainly the job of the API to hide any complexity in the protocol.

RG

C# API boilerplate

[Shahbaz Chaudhary <sc...@marcopolonetwork.com>]

I am going through examples of the new 0-10 client API and have noticed
that the API seems unnecessarily complex.

Some examples:
The IMessageListener interface has a callback method which receives an
IMessage object.  I expected IMessage to work in the following manner:

string x = message.getString("fieldname");
double y = message.getDouble("fieldname");
Dictionary<string,string> fieldsAndTheirTypes =
message.getFieldsNTypes();

Instead the example contains binary readers, bytes, encodings, etc.:

BinaryReader reader = new BinaryReader(m.Body, Encoding.UTF8);
byte[] body = new byte[m.Body.Length - m.Body.Position];
reader.Read(body, 0, body.Length);
ASCIIEncoding enc = new ASCIIEncoding();

-----
The code to create connection and session also looks unnecessarily
noisy.  I have to provide the queue name to the ClientSession object
three times (twice in one method call):

ssn.queueDeclare("queue1", null, null);
ssn.exchangeBind("queue1", "amq.direct", "queue1", null);
sn.messageSubscribe("queue1", "myDest", MessageAcceptMode.EXPLICIT,
MessageAcquireMode.PRE_ACQUIRED, null,0, null);

----
The call-back method in IMessageListener is called messageTransfer(),
isn't it better to simply call it onMessage()?

In fact, it looks like using JMS as the API template will greatly
improve the publicly exposed part of the API (and I used to think the
JMS API was messy :) ).

I think it will be a good idea to expose incoming message as
Events...since that's what incoming messages are and the semantics of
qpid subscribed messages and the Events feature match perfectly.

-----
I realize some of the complexity exists because AMQP provides many
features...perhaps qpid can provide a stupidly simple, default, way of
getting at the data within a few lines?

Client client = new Client("url");

client.subscribe("topicName1").OnMessage += {x =>
Console.WriteLine(x.getLong("bankaccount"))};;
client.subscribe("topicName2").OnMessage += {x =>
Console.WriteLine(x.getLong("bankaccount"))};;

//what ever the right C# syntax is for event handling and lambda
experssions
Sender sender client.getSender("topicName3");
client.connect();

IMessage msg = client.createMessageOfWhateverType();
msg.setLong("bankaccount",234134154123412342);
msg.setString("type","savings");

sender.send(msg);

Re: C# client for 0-10?

[Robert Greig <ro...@gmail.com>]

2008/12/3 Steve Huston <sh...@riverace.com>:

>> > I have no objections to them being checked in. However we
>> might want to
>> > create a starter JIRA
>> > fro someone to auto generate the vs project files -- or at
>> least see if that
>> > is possible.
>>
>> I'll raise a jira to fix the project files and check them in.
>
> This has been recorded...
> https://issues.apache.org/jira/browse/QPID-1498

I have had a look at this for .NET. The situation is much better than
C++ since msbuild allows you to specify wildcards in the build files -
this makes supporting generated code much simpler. Given this, is
there an advantage to generating project files?

I'm going to check in the fixed project files for M4 and updated
README. We can look at whether the target should be nant or msbuild
separately for a later release since there will be work I think to
review the .NET build process which will take longer than the time
available for M4.

RG

RE: C# client for 0-10?

[Steve Huston <sh...@riverace.com>]

Hi Robert,

Quick note...

> > I have no objections to them being checked in. However we 
> might want to
> > create a starter JIRA
> > fro someone to auto generate the vs project files -- or at 
> least see if that
> > is possible.
> 
> I'll raise a jira to fix the project files and check them in.

This has been recorded...
https://issues.apache.org/jira/browse/QPID-1498

-Steve

Re: C# client for 0-10?

[Robert Greig <ro...@gmail.com>]

2008/12/1 Carl Trieloff <cc...@redhat.com>:

Hi Carl,

Sorry for the delay - been on a business trip and have had zero time
to read the list.

> I don't believe msbuild can be run on mono, so I think we are stuck with at
> least nant. This means
> maintaining two sets of project files.

The mono guys have written an msbuild port - see
http://www.mono-project.com/Microsoft.Build

I don't use mono but could someone who does try it out to see if it works?

> I have no objections to them being checked in. However we might want to
> create a starter JIRA
> fro someone to auto generate the vs project files -- or at least see if that
> is possible.

I'll raise a jira to fix the project files and check them in. Once we
know whether the mono msbuild implementation is a flyer we can make a
decision about which is the right one strategically.

RG

SVN and LIST migration

[Carl Trieloff <cc...@redhat.com>]

I have put tickets in to have our lists updated and svn.

LISTS:

The new lists will be

dev@qpid.apache.org <ma...@qpid.apache.org> from 
qpid-dev@incubator.apache.org <ma...@incubator.apache.org>
users@qpid.apache.org <ma...@qpid.apache.org> from 
qpid-users@incubator.apache.org <ma...@incubator.apache.org>
commits@qpid.apache.org <ma...@qpid.apache.org> from 
qpid-commits@incubator.apache.org 
<ma...@incubator.apache.org>

The old list addresses will remain up and forward to the new lists

SVN:

svn will be a svn move from

/svn.apache.org/repos/asf/incubator/qpid

to

/svn.apache.org/repos/asf/qpid

regards
Carl.

Re: How do you assign a JIRA as a starter?

[Aidan Skinner <ai...@apache.org>]

There's a "Starter" component which can be added to it.

- Aidan

-- 
Apache Qpid - World Domination through Advanced Message Queueing
http://cwiki.apache.org/qpid
"Have we anything resembling a plan?" "Mm-hm. Ride till we find
them... and kill them all." - The 13th Warrior

Re: How do you assign a JIRA as a starter?

[Marnie McCormack <ma...@googlemail.com>]

Hi,

It's set up as a component, so simply edit the JIRA and add that component
should do the trick !

Hth,
Marnie

On Mon, Dec 1, 2008 at 8:20 PM, Carl Trieloff <cc...@redhat.com> wrote:

> Thanks
> Carl.
>

Re: How do you assign a JIRA as a starter?

[Carl Trieloff <cc...@redhat.com>]

Thanks
Carl.

Re: C# client for 0-10?

[Carl Trieloff <cc...@redhat.com>]

>
> Is the strategy to use nant as the main build system or VS project
> files and msbuild.exe?
>
> I have fixed the VS project files and can check them in obviously, but
> I first wanted to check if they are not being maintained since it may
> make more sense to delete them.
>
> The code also will not build on .NET 1.1 (it uses generics for a
> start) so I think the instructions and bat files need to be modified
> to reflect that.
>
> Incidentally, with nant or the fixed project files it builds on both
> 2.0 and 3.5.
>
>   

Rob,

I don't believe msbuild can be run on mono, so I think we are stuck with 
at least nant. This means
maintaining two sets of project files.

I have no objections to them being checked in. However we might want to 
create a starter JIRA
fro someone to auto generate the vs project files -- or at least see if 
that is possible.

Carl.

Re: C# client for 0-10?

[Robert Greig <ro...@gmail.com>]

2008/11/27 Carl Trieloff <cc...@redhat.com>:
>
> The build works on both mono and native. I expect that all that is needed is
> are minor
> updated to have it build on 2.0 and 3.5. I had assumed build on 2.0 and then
> run on anything.

I just tried it and it did not work for me. The readme says that you
can build using the Visual Studio solution files, or with nant, and
the build-dotnet20 script uses msbuild rather than nant. The VS
project files do not contain all the necessary files or references to
dependent assemblies (e.g. log4net).

Is the strategy to use nant as the main build system or VS project
files and msbuild.exe?

I have fixed the VS project files and can check them in obviously, but
I first wanted to check if they are not being maintained since it may
make more sense to delete them.

The code also will not build on .NET 1.1 (it uses generics for a
start) so I think the instructions and bat files need to be modified
to reflect that.

Incidentally, with nant or the fixed project files it builds on both
2.0 and 3.5.

RG