Hi Rajith,
I think we as a project *must* have the same connection url/string
syntax across all clients.
I don't think this works in the WCF context. But I believe it is
merely because WCF has different conventions, not that the proposal
lacks merit in general.
In WCF, the constituents of
Hi Jonathan,
Great stuff!
I'll try to put together some WCF/C++ client related material over the weekend.
Cheers.
Cliff
-Original Message-
From: Jonathan Robie [mailto:jonathan.ro...@redhat.com]
Sent: Thursday, March 11, 2010 6:32 AM
To: dev@qpid.apache.org
Subject: Qpid Wiki in
-Original Message-
From: Gordon Sim [mailto:g...@redhat.com]
Sent: Tuesday, March 09, 2010 5:37 AM
To: dev@qpid.apache.org
Subject: Re: QMF and .NET
On 03/08/2010 09:32 PM, Cliff Jansen (Interop Systems Inc) wrote:
Hi Gordon,
I'd suggest we don't focus exclusively on 'QMF' here
I agree
: QMF and .NET
On 03/08/2010 07:11 AM, Gordon Sim wrote:
On 03/05/2010 08:56 AM, Cliff Jansen (Interop Systems Inc) wrote:
Hi Carl,
I've taken a look at QMFv2 and hope I understand it well enough to
give useful feedback.
On the whole, I think your characterization of the options is correct
On 03/05/2010 08:56 AM, Cliff Jansen (Interop Systems Inc) wrote:
Hi Carl,
I've taken a look at QMFv2 and hope I understand it well enough to
give useful feedback.
On the whole, I think your characterization of the options is correct.
However, I would suggest you should not think of WCF merely
Hi Carl,
I've taken a look at QMFv2 and hope I understand it well enough to
give useful feedback.
On the whole, I think your characterization of the options is correct.
However, I would suggest you should not think of WCF merely as a SOAPy
WSDL provider, but more as a layered architecture. WCF
There are
certainly other csproj files with the license in at the top of the file
- do these cause problems for MSVC?
These C# project files are just XML. Putting the Apache license in
an XML comment at the top of the file will not adversely affect MSVC.
Cliff
-Original Message-
Subject: Re: WCF/C++ client feature work for 0.7
On 02/10/2010 07:41 AM, Cliff Jansen (Interop Systems Inc) wrote:
Hi Gordon,
I'd be keen to hear more of your thoughts an opinions on the new API
for the c++ client.
I will try to take another look at it shortly.
It would be worth seeing if we can
Thanks for the info, Cliff! You've done some great work on this.
On 02/04/2010 07:54 PM, Cliff Jansen (Interop Systems Inc) wrote:
The existing 0.6 version of the WCF/C++ client provides basic WCF
functionality. Its most significant additional feature is distributed
transaction support
Hi Kerry,
By coincidence, I have gone through the certificate learning curve in
the last few days.
The Windows broker currently supports registry based (as opposed to
file based) certificates that are in a certificate store that is
scoped to the local machine (not the current user). I am not up
The fixes you made on my behalf look good.
Thanks very much.
Cliff
-Original Message-
From: Andrew Stitcher [mailto:astitc...@redhat.com]
Sent: Tuesday, February 02, 2010 9:26 AM
To: Qpid Dev List
Subject: Fifth (and I hope final) Release Candidate for 0.6 qpid release
I've now
Please apply QPID-2378 to the 0.6 branch to pick up the WCF client
specific release notes
I'm sorry. I mean QPID-2313.
Cliff
-Original Message-
From: Cliff Jansen (Interop Systems Inc) [mailto:v-clj...@microsoft.com]
Sent: Friday, January 29, 2010 12:07 PM
To: dev@qpid.apache.org
Cliff can you comment on these bugs? Are they truly as important as
blocker/critical? If so unless there are patches attached to the jiras
very soon I think we'll have to omit the specific WCF source code from
this release [...]
Agreed. These were marked as such because they would make a
I have taken a first stab at providing the release artifact for
WCF. (QPID-2267)
Like the python and ruby cases, it consists of a static snapshot of
the relevant subdirectory.
Unlike those cases, it cannot be built by the user unless the C++
artifact is also downloaded and built to provide the
Another thing I have noticed is that there is no WCF component
artifact in the beta build, is that something we plan to release with
0.6?
Yes. I contacted Andrew about this yesterday. JIRA coming soon.
Cliff
-Original Message-
From: Robbie Gemmell [mailto:robbie.gemm...@gmail.com]
Robert Greig wrote:
Having said that, I did take a look at this question (could WCF be a
generic messaging API) for other reasons related to my day job a
while ago and concluded that it could be. You would simply have to
define some very simple contracts (e.g. with a single method
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
Robert Greig wrote:
Finally, there are performance issue with managed/non-managed heap
copies in Java that makes JNI unattractive (I don't know if this
applies to .NET too - although I did ask the question on this mailing
list some time ago without receiving any answer).
I'll take a stab at
The Linux C++ code base is certainly more mature, but features for Windows
users are under very active development.
New for 0.6 is a persistent store module, SSL support (shortly), a greatly
improved build experience.
Clustering support is high on the wish list, but planning and development on
Hi Ishara,
Hi Carl,
Thanks a lot for your reply.I,m interested to contribute to the C# client.
That would be great. I would be happy to give you any help to get
started.
Carl Trieloff wrote:
- Cliff from Microsoft has submitted a C# client over the C++ client.
This client is written in
I like the discussion on message content.
Given Alan's recent suggestions, I can easily envisage how an
implementation could optimize the Receiver case and lazily extract the
content from the underlying protocol frames into the form required by
the application, and avoid an intermediate memory
Hi Gordon,
Jonathan previously requested support for the stream operator and I've
had a tentative stab at exploring what that might look like as well.
In addition, I would like to see the some stream-ish functions that
are friendly to char* blobs that are not null terminated. Something
along
Ted Ross wrote:
Regarding the .Net client in general... It's my understanding that
there are some contributors at Microsoft that are working on this part
of the code but I don't know what the status of that work is. Maybe
somebody who knows will chime in.
Since David Ingham has just become a
The protocol_gen.mak step is only required if you are building straight
from the svn repository. Since you are building from the source distribution,
you should just proceed to building the broker or client from the qpid.sln
file in the src directory.
Cliff
-Original Message-
From:
Hi Danushka,
That was another subject I was going to broach for M5, probably on the heels of
the C++ build system.
I would suggest to export the needed symbols rather than all of them if
possible. I would also recommend defining the exports in source (as the Boost
libraries do), rather than
Hi all,
Windows is a newly supported C++ platform in M4 and we are beginning
to see some early adopters having difficulty.
May I suggest a Windows area on qpid.apache.org with:
- more elaborate install and run doc
- clear info on differences compared to the Linux implementation
i.e.
I would be very interested to join the conference call. Thanks.
Cliff
-Original Message-
From: Marnie McCormack [mailto:marnie.mccorm...@googlemail.com]
Sent: Thursday, January 08, 2009 1:53 AM
To: qpid-...@apache.org
Subject: Qpid .NET Strategy - Interested ?
All,
We are currently
27 matches
Mail list logo
