You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Joshua Kramer <jo...@globalherald.net> on 2009/02/17 16:58:21 UTC
Routing with Google Protocol Buffers
Howdy Folks,
I wanted to throw out an idea. Is anybody using QPid to pass messages
based on Google's Protocol Buffers (PB)? Would it be beneficial to write
an exchange that routes messages based on something like a jquery, only on
PB messages instead of XML?
I am using Protocol Buffers in a blog I'm creating. The front end, based
in Django, sends requests via PB through Qpid to some Rpython-based
modeling software I wrote. PB took less time to implement in Python than
a comparable XML solution would have taken.
>From the PB site: "Protocol buffers are what you use if your network link
is already saturated and your CPU's are already overused." They are 3 to
10 times smaller, and 20 to 100 times faster than XML. You write a
definition of your data's structure, then the PB compiler will give you
objects in Java, Python, or C++. Far easier to use than XML.
http://code.google.com/apis/protocolbuffers/
Cheers,
-Josh
--
-----
http://www.globalherald.net/jb01
GlobalHerald.NET, the Smarter Social Network! (tm)
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: License Compatibility: Google vs. Apache
Posted by Aidan Skinner <ai...@gmail.com>.
On Wed, Feb 18, 2009 at 5:33 PM, Joshua Kramer <jo...@globalherald.net> wrote:
> Does anyone know if the Google license is compatible with the Apache license
> under which QPid is released? If nobody knows offhand I'll do some research
> to find out.
That's the 3-clause BSD licence, which is category A according to
http://www.apache.org/legal/3party.html which is 100% compatible.
- Aidan
--
Apache Qpid - World Domination through Advanced Message Queueing
http://qpid.apache.org
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: License Compatibility: Google vs. Apache
Posted by Marc Poussin <ma...@gmail.com>.
After a quick reading, it seems that this licence is a BSD licence, so class
A and compatible with the ASF policy
Best,
Marc
On Wed, Feb 18, 2009 at 6:55 PM, Carl Trieloff <cc...@redhat.com>wrote:
>
> ASF Legal
>
> Requesting a quick clarification from the legal list. It is thought that
> the Google license being
> a basic BSD is a class one license for Apache.
>
> Can we confirm that we can use the license below (from Google) in an Apache
> project.
>
> thanks
> Carl.
>
>
>
> Joshua Kramer wrote:
>
>>
>> Oops! Here's the license text:
>>
>> Copyright 2008, Google Inc.
>> All rights reserved.
>>
>> Redistribution and use in source and binary forms, with or without
>> modification, are permitted provided that the following conditions are
>> met:
>>
>> * Redistributions of source code must retain the above copyright
>> notice, this list of conditions and the following disclaimer.
>> * Redistributions in binary form must reproduce the above
>> copyright notice, this list of conditions and the following disclaimer
>> in the documentation and/or other materials provided with the
>> distribution.
>> * Neither the name of Google Inc. nor the names of its
>> contributors may be used to endorse or promote products derived from
>> this software without specific prior written permission.
>>
>> THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
>> "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
>> LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
>> A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
>> OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
>> SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
>> LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
>> DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
>> THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
>> (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
>> OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>>
>> Code generated by the Protocol Buffer compiler is owned by the owner
>> of the input file used when generating it. This code is not
>> standalone and requires a support library to be linked with it. This
>> support library is itself covered by the above license.
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
Re: License Compatibility: Google vs. Apache
Posted by Carl Trieloff <cc...@redhat.com>.
Thanks, just wanted the validation
Carl.
Henri Yandell wrote:
> Yep - consider that a BSD license rather than a Google license.
>
> Seems to be equivalent to http://en.wikipedia.org/wiki/BSD_licenses.
>
> Hen
>
> On Wed, Feb 18, 2009 at 9:55 AM, Carl Trieloff <cc...@redhat.com> wrote:
>
>> ASF Legal
>>
>> Requesting a quick clarification from the legal list. It is thought that the
>> Google license being
>> a basic BSD is a class one license for Apache.
>>
>> Can we confirm that we can use the license below (from Google) in an Apache
>> project.
>>
>> thanks
>> Carl.
>>
>>
>>
>> Joshua Kramer wrote:
>>
>>> Oops! Here's the license text:
>>>
>>> Copyright 2008, Google Inc.
>>> All rights reserved.
>>>
>>> Redistribution and use in source and binary forms, with or without
>>> modification, are permitted provided that the following conditions are
>>> met:
>>>
>>> * Redistributions of source code must retain the above copyright
>>> notice, this list of conditions and the following disclaimer.
>>> * Redistributions in binary form must reproduce the above
>>> copyright notice, this list of conditions and the following disclaimer
>>> in the documentation and/or other materials provided with the
>>> distribution.
>>> * Neither the name of Google Inc. nor the names of its
>>> contributors may be used to endorse or promote products derived from
>>> this software without specific prior written permission.
>>>
>>> THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
>>> "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
>>> LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
>>> A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
>>> OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
>>> SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
>>> LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
>>> DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
>>> THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
>>> (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
>>> OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>>>
>>> Code generated by the Protocol Buffer compiler is owned by the owner
>>> of the input file used when generating it. This code is not
>>> standalone and requires a support library to be linked with it. This
>>> support library is itself covered by the above license.
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>> For additional commands, e-mail: legal-discuss-help@apache.org
>>
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: License Compatibility: Google vs. Apache
Posted by Henri Yandell <hy...@gmail.com>.
Yep - consider that a BSD license rather than a Google license.
Seems to be equivalent to http://en.wikipedia.org/wiki/BSD_licenses.
Hen
On Wed, Feb 18, 2009 at 9:55 AM, Carl Trieloff <cc...@redhat.com> wrote:
>
> ASF Legal
>
> Requesting a quick clarification from the legal list. It is thought that the
> Google license being
> a basic BSD is a class one license for Apache.
>
> Can we confirm that we can use the license below (from Google) in an Apache
> project.
>
> thanks
> Carl.
>
>
>
> Joshua Kramer wrote:
>>
>> Oops! Here's the license text:
>>
>> Copyright 2008, Google Inc.
>> All rights reserved.
>>
>> Redistribution and use in source and binary forms, with or without
>> modification, are permitted provided that the following conditions are
>> met:
>>
>> * Redistributions of source code must retain the above copyright
>> notice, this list of conditions and the following disclaimer.
>> * Redistributions in binary form must reproduce the above
>> copyright notice, this list of conditions and the following disclaimer
>> in the documentation and/or other materials provided with the
>> distribution.
>> * Neither the name of Google Inc. nor the names of its
>> contributors may be used to endorse or promote products derived from
>> this software without specific prior written permission.
>>
>> THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
>> "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
>> LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
>> A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
>> OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
>> SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
>> LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
>> DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
>> THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
>> (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
>> OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>>
>> Code generated by the Protocol Buffer compiler is owned by the owner
>> of the input file used when generating it. This code is not
>> standalone and requires a support library to be linked with it. This
>> support library is itself covered by the above license.
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: License Compatibility: Google vs. Apache
Posted by Carl Trieloff <cc...@redhat.com>.
ASF Legal
Requesting a quick clarification from the legal list. It is thought that
the Google license being
a basic BSD is a class one license for Apache.
Can we confirm that we can use the license below (from Google) in an
Apache project.
thanks
Carl.
Joshua Kramer wrote:
>
> Oops! Here's the license text:
>
> Copyright 2008, Google Inc.
> All rights reserved.
>
> Redistribution and use in source and binary forms, with or without
> modification, are permitted provided that the following conditions are
> met:
>
> * Redistributions of source code must retain the above copyright
> notice, this list of conditions and the following disclaimer.
> * Redistributions in binary form must reproduce the above
> copyright notice, this list of conditions and the following disclaimer
> in the documentation and/or other materials provided with the
> distribution.
> * Neither the name of Google Inc. nor the names of its
> contributors may be used to endorse or promote products derived from
> this software without specific prior written permission.
>
> THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
> "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
> LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
> A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
> OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
> SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
> LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
> DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
> THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
> (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
> OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>
> Code generated by the Protocol Buffer compiler is owned by the owner
> of the input file used when generating it. This code is not
> standalone and requires a support library to be linked with it. This
> support library is itself covered by the above license.
>
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: License Compatibility: Google vs. Apache
Posted by Carl Trieloff <cc...@redhat.com>.
ASF Legal
Requesting a quick clarification from the legal list. It is thought that
the Google license being
a basic BSD is a class one license for Apache.
Can we confirm that we can use the license below (from Google) in an
Apache project.
thanks
Carl.
Joshua Kramer wrote:
>
> Oops! Here's the license text:
>
> Copyright 2008, Google Inc.
> All rights reserved.
>
> Redistribution and use in source and binary forms, with or without
> modification, are permitted provided that the following conditions are
> met:
>
> * Redistributions of source code must retain the above copyright
> notice, this list of conditions and the following disclaimer.
> * Redistributions in binary form must reproduce the above
> copyright notice, this list of conditions and the following disclaimer
> in the documentation and/or other materials provided with the
> distribution.
> * Neither the name of Google Inc. nor the names of its
> contributors may be used to endorse or promote products derived from
> this software without specific prior written permission.
>
> THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
> "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
> LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
> A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
> OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
> SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
> LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
> DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
> THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
> (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
> OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>
> Code generated by the Protocol Buffer compiler is owned by the owner
> of the input file used when generating it. This code is not
> standalone and requires a support library to be linked with it. This
> support library is itself covered by the above license.
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: License Compatibility: Google vs. Apache
Posted by Carl Trieloff <cc...@redhat.com>.
ASF Legal
Requesting a quick clarification from the legal list. It is thought that
the Google license being
a basic BSD is a class one license for Apache.
Can we confirm that we can use the license below (from Google) in an
Apache project.
thanks
Carl.
Joshua Kramer wrote:
>
> Oops! Here's the license text:
>
> Copyright 2008, Google Inc.
> All rights reserved.
>
> Redistribution and use in source and binary forms, with or without
> modification, are permitted provided that the following conditions are
> met:
>
> * Redistributions of source code must retain the above copyright
> notice, this list of conditions and the following disclaimer.
> * Redistributions in binary form must reproduce the above
> copyright notice, this list of conditions and the following disclaimer
> in the documentation and/or other materials provided with the
> distribution.
> * Neither the name of Google Inc. nor the names of its
> contributors may be used to endorse or promote products derived from
> this software without specific prior written permission.
>
> THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
> "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
> LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
> A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
> OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
> SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
> LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
> DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
> THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
> (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
> OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>
> Code generated by the Protocol Buffer compiler is owned by the owner
> of the input file used when generating it. This code is not
> standalone and requires a support library to be linked with it. This
> support library is itself covered by the above license.
>
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: License Compatibility: Google vs. Apache
Posted by Joshua Kramer <jo...@globalherald.net>.
Oops! Here's the license text:
Copyright 2008, Google Inc.
All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are
met:
* Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
* Redistributions in binary form must reproduce the above
copyright notice, this list of conditions and the following disclaimer
in the documentation and/or other materials provided with the
distribution.
* Neither the name of Google Inc. nor the names of its
contributors may be used to endorse or promote products derived from
this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
Code generated by the Protocol Buffer compiler is owned by the owner
of the input file used when generating it. This code is not
standalone and requires a support library to be linked with it. This
support library is itself covered by the above license.
--
-----
http://www.globalherald.net/jb01
GlobalHerald.NET, the Smarter Social Network! (tm)
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
License Compatibility: Google vs. Apache
Posted by Joshua Kramer <jo...@globalherald.net>.
(This is a subthread of the Protocol Buffers discussion I started)
Does anyone know if the Google license is compatible with the Apache
license under which QPid is released? If nobody knows offhand I'll do
some research to find out.
I would like to take some code from the Protocol Buffers utilities (beyond
the libraries themselves) to use in creating the PB exchange that I
discussed in a previous thread. The COPYING.txt present in the PB
distribution is reproduced in its entirety below.
Thanks,
-Josh
--
-----
http://www.globalherald.net/jb01
GlobalHerald.NET, the Smarter Social Network! (tm)
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: Routing with Google Protocol Buffers
Posted by Carl Trieloff <cc...@redhat.com>.
Apache Legal has confirmed we may use the license for PB - class A.
enjoy
Carl.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Routing with Google Protocol Buffers
Posted by Rafael Schloming <ra...@redhat.com>.
Jonathan Robie wrote:
> OK, I see the problem now.
>
> There's a text representation:
>
> http://code.google.com/apis/protocolbuffers/docs/overview.html
>
> # Textual representation of a protocol buffer.
> # This is *not* the binary format used on the wire.
> person {
> name: "John Doe"
> email: "jdoe@example.com"
> }
>
>
> But this is not what actually goes over the wire. And what goes over the
> wire does not include the names. To quote the above overview:
>
>> XML is also – to some extent – self-describing. A protocol buffer is
>> only meaningful if you have the message definition (the |.proto| file).
>
> So I agree with John. The native PB format doesn't contain the names we
> need to query them. The text format does, but this is not the native
> format.
This doesn't mean you can't do it, simply that you would need some sort
of header to indicate what kind of protocol buffer the message contains.
For example you could include a header that references a published
.proto file, much like an XML document references a dtd or schema.
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Routing with Google Protocol Buffers
Posted by Jonathan Robie <jo...@redhat.com>.
OK, I see the problem now.
There's a text representation:
http://code.google.com/apis/protocolbuffers/docs/overview.html
# Textual representation of a protocol buffer.
# This is *not* the binary format used on the wire.
person {
name: "John Doe"
email: "jdoe@example.com"
}
But this is not what actually goes over the wire. And what goes over the
wire does not include the names. To quote the above overview:
> XML is also – to some extent – self-describing. A protocol buffer is
> only meaningful if you have the message definition (the |.proto| file).
So I agree with John. The native PB format doesn't contain the names we
need to query them. The text format does, but this is not the native format.
Jonathan
John O'Hara wrote:
> "The exchange then opens the protocol spec file and determines the key
> number of the field we want."
> So the broker needs to have access to the application message definitions at
> runtime?
>
> That was at the heart of the question I asked...
>
> Cheers
> John
>
> 2009/2/22 Joshua Kramer <jo...@globalherald.net>
>
>
>> I agree that it's preferable to have one exchange handle multiple message
>> types, as it reduces code maintenance. Here are a few relevant questions
>> that I thought of.
>>
>> Does XQuilla require the entire XML document, or can its document
>> projection feature tell you how much of the PB message you have to XML-ify
>> before it can get a valid match?
>>
>> How much value would a speed increase provide on structured data? Does
>> this discussion have practical value, or is it just a science experiment?
>>
>> If I were to implement a PB exchange, I would do so in the following
>> manner, after having read the documentation on message formats (
>> http://code.google.com/apis/protocolbuffers/docs/encoding.html). I don't
>> think I would implement a new query language; that doesn't make sense for
>> the reasons you outlined. I don't think it would be difficult to implement
>> an XPath mechanism, if it contained a subset of XPath.
>>
>> A. On exchange subscription, the client gives the exchange an XPath query.
>> The exchange then opens the protocol spec file and determines the key
>> number of the field we want. If the requested element is at the top level,
>> the rule is simple: field n equals value y. If the requested element is one
>> or more levels deep, we build a rule chain: first, get field n; then, get
>> field o; then, get field p. (Field p is in the object that is field o,
>> which in turn is in the object that is field n).
>>
>> B. When we get a message:
>> 1. If the MSB = 0 AND we are not working on something, skip to next
>> byte.
>> 2. If the MSB = 1:
>> i. right-shift 1 step. Does the field number equal the one
>> we're referencing? If yes:
>> a. Get the data and move forward the number of bytes
>> specified by the type and length.
>> b. Test the data to see if it matches the right of the =
>> in the XPath. If yes, route the message as specified by the subscription
>> and return.
>> c. If the XPath rule is a chain, and the data matches this
>> link, then repeat from step 2 on this particular object using the next link
>> in the rulechain.
>> d. Goto 1.
>> ii. If no:
>> a. Skip the number of bytes specified in the type and
>> length.
>> b. Goto 1.
>>
>> It seems that this would use fewer CPU cycles than XML-ifying the entire
>> message, and that doesn't include running the resulting data through
>> XQzilla.
>>
>> Having said that - it may be necessary to use the full set of XPath
>> functionality, and in that case we'd have to XMLify the message.
>>
>> Thoughts?
>>
>> Cheers,
>> -Josh
>>
>>
>> Jonathan Robie wrote:
>>
>>
>>> Joshua Kramer wrote:
>>>
>>>
>>>> Jonathan Robie wrote:
>>>>
>>>>
>>>>> There is a reflection API for protocol buffers that would allow you to
>>>>> easily create an XML representation:
>>>>>
>>>>>
>>>> Good thoughts, Jonathan. I hadn't considered doing it that way before.
>>>> Here's a question, though... how many CPU cycles would your method take,
>>>> compared to modifying XQuilla (or creating our own query mechanism) to
>>>> directly route the messages as they exist in the wire format they enter the
>>>> broker? One of the primary benefits of using PB with QPid is the speed with
>>>> which structured data may be processed.
>>>>
>>>>
>>> I rather suspect that the difference in processing time would be much
>>> smaller than the overhead of reading the message, but this is something best
>>> found by trying it and measuring it, then optimizing. If we can get good
>>> enough performance, I see a real advantage to using one exchange type for
>>> XML, Protocol Buffers, and JSON, and using the same language to specify
>>> criteria for all three.
>>>
>>> If we create our own query mechanism, we wind up creating our own query
>>> language, I've done this a few times in different settings, and it takes
>>> work to get it right. And it would be a language used by a very small
>>> community. If we use a standard structured query language, XQuery seems to
>>> be the main contender.
>>>
>>> XQilla can query many kinds of input - a Xerces DOM tree, an istream
>>> (which requires serialized XML), a SAX Stream, among others. It probably
>>> optimizes best for an istream, because it does "document projection", which
>>> means that it does not parse the entire document if the query clearly
>>> requires only part of the document. This is of most benefit when the
>>> message content is large.
>>>
>>> Jonathan
>>>
>>> ---------------------------------------------------------------------
>>> Apache Qpid - AMQP Messaging Implementation
>>> Project: http://qpid.apache.org
>>> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> Apache Qpid - AMQP Messaging Implementation
>> Project: http://qpid.apache.org
>> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>>
>>
>>
>
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Routing with Google Protocol Buffers
Posted by John O'Hara <jo...@gmail.com>.
"The exchange then opens the protocol spec file and determines the key
number of the field we want."
So the broker needs to have access to the application message definitions at
runtime?
That was at the heart of the question I asked...
Cheers
John
2009/2/22 Joshua Kramer <jo...@globalherald.net>
> I agree that it's preferable to have one exchange handle multiple message
> types, as it reduces code maintenance. Here are a few relevant questions
> that I thought of.
>
> Does XQuilla require the entire XML document, or can its document
> projection feature tell you how much of the PB message you have to XML-ify
> before it can get a valid match?
>
> How much value would a speed increase provide on structured data? Does
> this discussion have practical value, or is it just a science experiment?
>
> If I were to implement a PB exchange, I would do so in the following
> manner, after having read the documentation on message formats (
> http://code.google.com/apis/protocolbuffers/docs/encoding.html). I don't
> think I would implement a new query language; that doesn't make sense for
> the reasons you outlined. I don't think it would be difficult to implement
> an XPath mechanism, if it contained a subset of XPath.
>
> A. On exchange subscription, the client gives the exchange an XPath query.
> The exchange then opens the protocol spec file and determines the key
> number of the field we want. If the requested element is at the top level,
> the rule is simple: field n equals value y. If the requested element is one
> or more levels deep, we build a rule chain: first, get field n; then, get
> field o; then, get field p. (Field p is in the object that is field o,
> which in turn is in the object that is field n).
>
> B. When we get a message:
> 1. If the MSB = 0 AND we are not working on something, skip to next
> byte.
> 2. If the MSB = 1:
> i. right-shift 1 step. Does the field number equal the one
> we're referencing? If yes:
> a. Get the data and move forward the number of bytes
> specified by the type and length.
> b. Test the data to see if it matches the right of the =
> in the XPath. If yes, route the message as specified by the subscription
> and return.
> c. If the XPath rule is a chain, and the data matches this
> link, then repeat from step 2 on this particular object using the next link
> in the rulechain.
> d. Goto 1.
> ii. If no:
> a. Skip the number of bytes specified in the type and
> length.
> b. Goto 1.
>
> It seems that this would use fewer CPU cycles than XML-ifying the entire
> message, and that doesn't include running the resulting data through
> XQzilla.
>
> Having said that - it may be necessary to use the full set of XPath
> functionality, and in that case we'd have to XMLify the message.
>
> Thoughts?
>
> Cheers,
> -Josh
>
>
> Jonathan Robie wrote:
>
>> Joshua Kramer wrote:
>>
>>> Jonathan Robie wrote:
>>>
>>>> There is a reflection API for protocol buffers that would allow you to
>>>> easily create an XML representation:
>>>>
>>> Good thoughts, Jonathan. I hadn't considered doing it that way before.
>>> Here's a question, though... how many CPU cycles would your method take,
>>> compared to modifying XQuilla (or creating our own query mechanism) to
>>> directly route the messages as they exist in the wire format they enter the
>>> broker? One of the primary benefits of using PB with QPid is the speed with
>>> which structured data may be processed.
>>>
>> I rather suspect that the difference in processing time would be much
>> smaller than the overhead of reading the message, but this is something best
>> found by trying it and measuring it, then optimizing. If we can get good
>> enough performance, I see a real advantage to using one exchange type for
>> XML, Protocol Buffers, and JSON, and using the same language to specify
>> criteria for all three.
>>
>> If we create our own query mechanism, we wind up creating our own query
>> language, I've done this a few times in different settings, and it takes
>> work to get it right. And it would be a language used by a very small
>> community. If we use a standard structured query language, XQuery seems to
>> be the main contender.
>>
>> XQilla can query many kinds of input - a Xerces DOM tree, an istream
>> (which requires serialized XML), a SAX Stream, among others. It probably
>> optimizes best for an istream, because it does "document projection", which
>> means that it does not parse the entire document if the query clearly
>> requires only part of the document. This is of most benefit when the
>> message content is large.
>>
>> Jonathan
>>
>> ---------------------------------------------------------------------
>> Apache Qpid - AMQP Messaging Implementation
>> Project: http://qpid.apache.org
>> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
Re: Routing with Google Protocol Buffers
Posted by Joshua Kramer <jo...@globalherald.net>.
I agree that it's preferable to have one exchange handle multiple
message types, as it reduces code maintenance. Here are a few relevant
questions that I thought of.
Does XQuilla require the entire XML document, or can its document
projection feature tell you how much of the PB message you have to
XML-ify before it can get a valid match?
How much value would a speed increase provide on structured data? Does
this discussion have practical value, or is it just a science experiment?
If I were to implement a PB exchange, I would do so in the following
manner, after having read the documentation on message formats
(http://code.google.com/apis/protocolbuffers/docs/encoding.html). I
don't think I would implement a new query language; that doesn't make
sense for the reasons you outlined. I don't think it would be difficult
to implement an XPath mechanism, if it contained a subset of XPath.
A. On exchange subscription, the client gives the exchange an XPath
query. The exchange then opens the protocol spec file and determines
the key number of the field we want. If the requested element is at the
top level, the rule is simple: field n equals value y. If the requested
element is one or more levels deep, we build a rule chain: first, get
field n; then, get field o; then, get field p. (Field p is in the
object that is field o, which in turn is in the object that is field n).
B. When we get a message:
1. If the MSB = 0 AND we are not working on something, skip to
next byte.
2. If the MSB = 1:
i. right-shift 1 step. Does the field number equal the one
we're referencing? If yes:
a. Get the data and move forward the number of bytes
specified by the type and length.
b. Test the data to see if it matches the right of
the = in the XPath. If yes, route the message as specified by the
subscription and return.
c. If the XPath rule is a chain, and the data matches
this link, then repeat from step 2 on this particular object using the
next link in the rulechain.
d. Goto 1.
ii. If no:
a. Skip the number of bytes specified in the type and
length.
b. Goto 1.
It seems that this would use fewer CPU cycles than XML-ifying the entire
message, and that doesn't include running the resulting data through
XQzilla.
Having said that - it may be necessary to use the full set of XPath
functionality, and in that case we'd have to XMLify the message.
Thoughts?
Cheers,
-Josh
Jonathan Robie wrote:
> Joshua Kramer wrote:
>> Jonathan Robie wrote:
>>> There is a reflection API for protocol buffers that would allow you
>>> to easily create an XML representation:
>> Good thoughts, Jonathan. I hadn't considered doing it that way
>> before. Here's a question, though... how many CPU cycles would your
>> method take, compared to modifying XQuilla (or creating our own query
>> mechanism) to directly route the messages as they exist in the wire
>> format they enter the broker? One of the primary benefits of using
>> PB with QPid is the speed with which structured data may be processed.
> I rather suspect that the difference in processing time would be much
> smaller than the overhead of reading the message, but this is
> something best found by trying it and measuring it, then optimizing.
> If we can get good enough performance, I see a real advantage to using
> one exchange type for XML, Protocol Buffers, and JSON, and using the
> same language to specify criteria for all three.
>
> If we create our own query mechanism, we wind up creating our own
> query language, I've done this a few times in different settings, and
> it takes work to get it right. And it would be a language used by a
> very small community. If we use a standard structured query language,
> XQuery seems to be the main contender.
>
> XQilla can query many kinds of input - a Xerces DOM tree, an istream
> (which requires serialized XML), a SAX Stream, among others. It
> probably optimizes best for an istream, because it does "document
> projection", which means that it does not parse the entire document if
> the query clearly requires only part of the document. This is of most
> benefit when the message content is large.
>
> Jonathan
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Routing with Google Protocol Buffers
Posted by Jonathan Robie <jo...@redhat.com>.
Joshua Kramer wrote:
> Jonathan Robie wrote:
>> There is a reflection API for protocol buffers that would allow you
>> to easily create an XML representation:
> Good thoughts, Jonathan. I hadn't considered doing it that way
> before. Here's a question, though... how many CPU cycles would your
> method take, compared to modifying XQuilla (or creating our own query
> mechanism) to directly route the messages as they exist in the wire
> format they enter the broker? One of the primary benefits of using PB
> with QPid is the speed with which structured data may be processed.
I rather suspect that the difference in processing time would be much
smaller than the overhead of reading the message, but this is something
best found by trying it and measuring it, then optimizing. If we can get
good enough performance, I see a real advantage to using one exchange
type for XML, Protocol Buffers, and JSON, and using the same language to
specify criteria for all three.
If we create our own query mechanism, we wind up creating our own query
language, I've done this a few times in different settings, and it takes
work to get it right. And it would be a language used by a very small
community. If we use a standard structured query language, XQuery seems
to be the main contender.
XQilla can query many kinds of input - a Xerces DOM tree, an istream
(which requires serialized XML), a SAX Stream, among others. It
probably optimizes best for an istream, because it does "document
projection", which means that it does not parse the entire document if
the query clearly requires only part of the document. This is of most
benefit when the message content is large.
Jonathan
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Routing with Google Protocol Buffers
Posted by Joshua Kramer <jo...@globalherald.net>.
Jonathan Robie wrote:
> There is a reflection API for protocol buffers that would allow you to
> easily create an XML representation:
Good thoughts, Jonathan. I hadn't considered doing it that way before.
Here's a question, though... how many CPU cycles would your method take,
compared to modifying XQuilla (or creating our own query mechanism) to
directly route the messages as they exist in the wire format they enter
the broker? One of the primary benefits of using PB with QPid is the
speed with which structured data may be processed.
Cheers,
-Josh
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Routing with Google Protocol Buffers
Posted by Jonathan Robie <jo...@redhat.com>.
There is a reflection API for protocol buffers that would allow you to
easily create an XML representation:
http://code.google.com/apis/protocolbuffers/docs/reference/cpp/google.protobuf.message.html#Reflection
The XQilla query processor used in the XML Exchange can accept data in a
variety of ways, I will be changing it to serialize message content as
an istream in the near future. The easiest way to support Protocol
Buffers would be to set a Mime Type in the message so it's clear that
it's a Protocol Buffer, then have the serializer use the Protocol Buffer
Reflection API to serialize the message as XML, so the existing XML
Exchange can query and route it. The same approach could be used for JSON.
I'd be glad to help with this.
Jonathan
John O'Hara wrote:
> I thought that PB didn't have tagged data like XML does? So how would the
> broker find out the message definitions?
> Won't that make it awkward for jquery/xquery - or am I missing something?
>
> Nice idea though.
> John
>
> 2009/2/17 Carl Trieloff <cc...@redhat.com>
>
>
>> Joshua Kramer wrote:
>>
>>
>>> Howdy Folks,
>>>
>>> I wanted to throw out an idea. Is anybody using QPid to pass messages
>>> based on Google's Protocol Buffers (PB)? Would it be beneficial to write an
>>> exchange that routes messages based on something like a jquery, only on PB
>>> messages instead of XML?
>>>
>>> I am using Protocol Buffers in a blog I'm creating. The front end, based
>>> in Django, sends requests via PB through Qpid to some Rpython-based modeling
>>> software I wrote. PB took less time to implement in Python than a
>>> comparable XML solution would have taken.
>>>
>>> From the PB site: "Protocol buffers are what you use if your network link
>>> is already saturated and your CPU's are already overused." They are 3 to 10
>>> times smaller, and 20 to 100 times faster than XML. You write a definition
>>> of your data's structure, then the PB compiler will give you objects in
>>> Java, Python, or C++. Far easier to use than XML.
>>>
>>> http://code.google.com/apis/protocolbuffers/
>>>
>>> Cheers,
>>> -Josh
>>>
>>>
>>>
>> Josh,
>>
>> I expect it would be quite easy to do, I have skimmed the PB stuff. The XML
>> XQuery exchange is a plugin to the broker which is much
>> the same pattern and can be found here
>>
>> https://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/qpid/xml/
>>
>> As you can see, it subclasses the exchange, and when the plugin loads it
>> registers the XQuery exchange. This part would be 90%
>> the same for PB plugin.
>>
>> In
>> https://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/qpid/xml/XmlExchange.cppyou would have to re-implement specifically for PB,
>> i.e. how you want binding specified, and what lib to call on the PB side,
>> or code the routing part.
>>
>> I would copy the xml dir to protocolBuffer dir and use these 4 files as the
>> starting point for a PB exchange plug-in.
>>
>> Finally, there is a .mk one level up that will need the PB plugin added to
>> the make process. If you do the PB stuff etc, I'll be glad to help
>> with the project integration stuff.
>>
>> regards
>> Carl.
>>
>>
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> Apache Qpid - AMQP Messaging Implementation
>> Project: http://qpid.apache.org
>> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>>
>>
>>
>
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Routing with Google Protocol Buffers
Posted by John O'Hara <jo...@gmail.com>.
I thought that PB didn't have tagged data like XML does? So how would the
broker find out the message definitions?
Won't that make it awkward for jquery/xquery - or am I missing something?
Nice idea though.
John
2009/2/17 Carl Trieloff <cc...@redhat.com>
> Joshua Kramer wrote:
>
>>
>> Howdy Folks,
>>
>> I wanted to throw out an idea. Is anybody using QPid to pass messages
>> based on Google's Protocol Buffers (PB)? Would it be beneficial to write an
>> exchange that routes messages based on something like a jquery, only on PB
>> messages instead of XML?
>>
>> I am using Protocol Buffers in a blog I'm creating. The front end, based
>> in Django, sends requests via PB through Qpid to some Rpython-based modeling
>> software I wrote. PB took less time to implement in Python than a
>> comparable XML solution would have taken.
>>
>> From the PB site: "Protocol buffers are what you use if your network link
>> is already saturated and your CPU's are already overused." They are 3 to 10
>> times smaller, and 20 to 100 times faster than XML. You write a definition
>> of your data's structure, then the PB compiler will give you objects in
>> Java, Python, or C++. Far easier to use than XML.
>>
>> http://code.google.com/apis/protocolbuffers/
>>
>> Cheers,
>> -Josh
>>
>>
> Josh,
>
> I expect it would be quite easy to do, I have skimmed the PB stuff. The XML
> XQuery exchange is a plugin to the broker which is much
> the same pattern and can be found here
>
> https://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/qpid/xml/
>
> As you can see, it subclasses the exchange, and when the plugin loads it
> registers the XQuery exchange. This part would be 90%
> the same for PB plugin.
>
> In
> https://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/qpid/xml/XmlExchange.cppyou would have to re-implement specifically for PB,
> i.e. how you want binding specified, and what lib to call on the PB side,
> or code the routing part.
>
> I would copy the xml dir to protocolBuffer dir and use these 4 files as the
> starting point for a PB exchange plug-in.
>
> Finally, there is a .mk one level up that will need the PB plugin added to
> the make process. If you do the PB stuff etc, I'll be glad to help
> with the project integration stuff.
>
> regards
> Carl.
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
Re: Routing with Google Protocol Buffers
Posted by Carl Trieloff <cc...@redhat.com>.
Joshua Kramer wrote:
>
> Howdy Folks,
>
> I wanted to throw out an idea. Is anybody using QPid to pass messages
> based on Google's Protocol Buffers (PB)? Would it be beneficial to
> write an exchange that routes messages based on something like a
> jquery, only on PB messages instead of XML?
>
> I am using Protocol Buffers in a blog I'm creating. The front end,
> based in Django, sends requests via PB through Qpid to some
> Rpython-based modeling software I wrote. PB took less time to
> implement in Python than a comparable XML solution would have taken.
>
> From the PB site: "Protocol buffers are what you use if your network
> link is already saturated and your CPU's are already overused." They
> are 3 to 10 times smaller, and 20 to 100 times faster than XML. You
> write a definition of your data's structure, then the PB compiler will
> give you objects in Java, Python, or C++. Far easier to use than XML.
>
> http://code.google.com/apis/protocolbuffers/
>
> Cheers,
> -Josh
>
Josh,
I expect it would be quite easy to do, I have skimmed the PB stuff. The
XML XQuery exchange is a plugin to the broker which is much
the same pattern and can be found here
https://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/qpid/xml/
As you can see, it subclasses the exchange, and when the plugin loads it
registers the XQuery exchange. This part would be 90%
the same for PB plugin.
In
https://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/qpid/xml/XmlExchange.cpp
you would have to re-implement specifically for PB,
i.e. how you want binding specified, and what lib to call on the PB
side, or code the routing part.
I would copy the xml dir to protocolBuffer dir and use these 4 files as
the starting point for a PB exchange plug-in.
Finally, there is a .mk one level up that will need the PB plugin added
to the make process. If you do the PB stuff etc, I'll be glad to help
with the project integration stuff.
regards
Carl.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Routing with Google Protocol Buffers
Posted by Carl Trieloff <cc...@redhat.com>.
Joshua Kramer wrote:
>
> Howdy Folks,
>
> I wanted to throw out an idea. Is anybody using QPid to pass messages
> based on Google's Protocol Buffers (PB)? Would it be beneficial to
> write an exchange that routes messages based on something like a
> jquery, only on PB messages instead of XML?
>
> I am using Protocol Buffers in a blog I'm creating. The front end,
> based in Django, sends requests via PB through Qpid to some
> Rpython-based modeling software I wrote. PB took less time to
> implement in Python than a comparable XML solution would have taken.
>
> From the PB site: "Protocol buffers are what you use if your network
> link is already saturated and your CPU's are already overused." They
> are 3 to 10 times smaller, and 20 to 100 times faster than XML. You
> write a definition of your data's structure, then the PB compiler will
> give you objects in Java, Python, or C++. Far easier to use than XML.
>
> http://code.google.com/apis/protocolbuffers/
>
> Cheers,
> -Josh
>
Josh,
I expect it would be quite easy to do, I have skimmed the PB stuff. The
XML XQuery exchange is a plugin to the broker which is much
the same pattern and can be found here
https://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/qpid/xml/
As you can see, it subclasses the exchange, and when the plugin loads it
registers the XQuery exchange. This part would be 90%
the same for PB plugin.
In
https://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/qpid/xml/XmlExchange.cpp
you would have to re-implement specifically for PB,
i.e. how you want binding specified, and what lib to call on the PB
side, or code the routing part.
I would copy the xml dir to protocolBuffer dir and use these 4 files as
the starting point for a PB exchange plug-in.
Finally, there is a .mk one level up that will need the PB plugin added
to the make process. If you do the PB stuff etc, I'll be glad to help
with the project integration stuff.
regards
Carl.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org