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:[email protected]
