[clarification] Repeated Header Entries
Hiram Chirino
most of a SEND frame when it get sent to the server as a MESSAGE
frame. The server should only need to strip off the 'SEND'
command/verb and prepend MESSAGE plus any additional headers it needs
to add to the message.
This implies that it may be possible to get repeated header entries.
Generally I think the first value should be considered the latest
update of the header field. I could also see some header fields being
treated as holding an array of values, and each repeated header could
be an entry in that array.
--
Regards,
Hiram
Blog: http://hiramchirino.com
Open Source SOA
http://fusesource.com/
Ian Eccles
repeated headers. They could be used to allow a SEND frame
to be sent to multiple destinations, or allow ACK or RECEIPT
frames to explicitly reference multiple messages.
Dejan Bosanac
--
Dejan Bosanac - http://twitter.com/dejanb
Open Source Integration - http://fusesource.com/
ActiveMQ in Action - http://www.manning.com/snyder/
Blog - http://www.nighttale.net
Lionel Cons
> I like the idea of representing an array of data through
> repeated headers. They could be used to allow a SEND frame
> to be sent to multiple destinations, or allow ACK or RECEIPT
> frames to explicitly reference multiple messages.
You can achieve the same thing without repeated headers:
foo:a -> foo:a b
foo:b
Both approaches are possible, we have to look at the consequences
(e.g. client side API) before choosing one.
Cheers,
Lionel
Ian Eccles
On Jun 16, 4:53 am, Lionel Cons <lionel.c...@cern.ch> wrote:
>
> You can achieve the same thing without repeated headers:
>
> foo:a -> foo:a b
> foo:b
>
> Both approaches are possible, we have to look at the consequences
> (e.g. client side API) before choosing one.
My preference for repeated headers is that it bypasses the issue of
escaping header values when the delimiter is being used as part of the
value. For instance:
destination:/topic/some topic
destination:/topic/other
converted to a single header as:
destination:"/topic/some topic" /topic/other
With a repeated headers, a client or broker doesn't have to change how
it parses headers; although it does have to respond to multiple
headers. With a delimited header, the parser itself would have to be
changed in addition to changing how it responds to delimited headers.
Playing devil's advocate to myself, headers with repeated keys could
be significantly larger than those with delimited values. For certain
STOMP frames, these differences in header sizes could significantly
impact the overall frame size.
Komuny
destination: ["/topic/some topic", "/topic/other"]
Hiram Chirino
Plus JSON strings can encode the \n control char. i.e.
MESSAGE
comment:"1. Overview\n\nThis header is using encoded newlines."
destination:STOMP.SPEC
hello world
^@
I'm partial to having a repeated header just mean that a header value
was updated during the routing of the message. Newer/Updated headers
go on top. I think this is similar to how SMTP works no? The nice
part about that is the routing intermediaries and very efficiently
update header entries since they don't need to mutate the original
message. Further more, clients can inspect how header values changed
as the message was routed through intermediate nodes. For example,
first thing a broker does to a message is add an
'received-on:${hostname}:${port}' header before it does things like
add headers for message-id, or redelivery count etc. If the message
is being forwarded through a federation of brokers it could end up
looking like:
MESSAGE
redeliveries:3
received-on:foo.host.com:61613
message-id:123
redeliveries:1
received-on:bar.host.com:61613
destination:/queue/a
hello world
^@
A client that gets the above message should interpret the message as
it were just sent:
MESSAGE
redeliveries:3
received-on:foo.host.com:61613
message-id:123
destination:/queue/a
hello world
^@
What do you think?
--
gmallard
Any potential increase in header size is more than offset by other
benefits - carefully crafted clients will spend a lot less time
actually putting data on the wire.
morellon
I agree that it gives the possibility of reducing server overhead, but
I see headers as being key-value (so a header is unique to me) and the
server should parse the headers looking for those it is interested on.
Also IMHO stomp is supposed to be a simple protocol, not a fast one.
I may be making the protocol more complicated by suggesting this, but
why not defining a header for knowing the routing activity?
Hiram Chirino
working on a server implementation the can sustain a pub/sub producer
sending upwards of 100,000 msg/sec to 10 connected subscribers.
That's 1,000,000 msg/sec that consumers are receiving.
Plus I think it makes the STOMP spec simpler in a way. The fact is
that duplicate headers COULD be in a frame. Making that an error
condition complicates implementations even more since they have to
check for the error condition. Making it the rule that only the first
value should be used simplifies it.
--
morellon
apologize for that.
What I meant was I prefer keeping it simple rather then optimizing it
for lower overheads, maybe your suggestion gives us both.
Nice work with your brokers/consumers there! :-)
But I still don't feel it makes simpler by allowing multiple headers.
I like looking at a stomp frame and seeing it is brief without
excessive headers that won't be useful for brokers or consumers.
I saw that SMTP only repeats the header 'Received'. Does it repeats
any other header? Is there any other protocol with repeated headers?
It would be nice to know about other protocols, so I can convince my
self.
Lionel Cons
> Plus I think it makes the STOMP spec simpler in a way.
I'm probably biased because I wrote a STOMP client and not a STOMP
server but I have the feeling that we also have to look at the
consequences at the API level. What will the API user see?
When the library code parses "foo:bar", how can it know if "foo"
should be associated with a single value or with a list containing one
element?
In other words (sorry for the Perl code), will the user of the API see:
$header{foo} = "bar"
or
$header{foo} = [ "bar" ]
or something else?
Cheers,
Lionel
Hiram Chirino
MESSAGE
foo:bar
foo:other
foo:you get the idea
^@
That API layers should just return "bar" to the user when he asks for
the "foo" header. This should maintain API compatibility with current
STOMP clients APIs. It's just that the 1.1 client libs would need to
make sure they ignore the subsequent duplicate header entries which
they may or may not be currently what they doing since the current
spec is does not specify what to do in this case.
Regards,
Hiram
--
Ian Eccles
as updated information. Consider the following:
MESSAGE
redeliveries:3
received-on:foo.host.com:61613
message-id:123
redeliveries:1
received-on:bar.host.com:61613
destination:/queue/a
destination:/queue/c
The 'received-on' header conceptually represents a stack (or a queue,
if the most recent update were last instead of first.) The
'destination' header is an array, but in essence both are just lists.
The only issue I can see with using the same mechanics to represent
both conditions is if a header fell into both categories. That is, a
repeated header representing an array were additionally repeated to
represent updates to state information. I'm trying to come up with a
realistic example to illustrate this possibility but am having some
trouble.
If there is a real use case where a header containing a list (through
repeated headers) could also be updated (through repeated headers),
then the repeated header syntax could very well produce ambiguous
messages. However, if such an example does not exist, using repeated
headers to conceptually represent lists seems more in line with the
STOMP spirit than a JSON or other string serialization of complex data
types.
I'm not trying to be inflexible on this, I'd just like to investigate
further whether repeated headers can meet both sets of needs. If not,
then I support using them for SMTP-style purposes to communicate state
transitions, as there is already strong precedent, and we can look to
some other representation of lists / collections.
Hiram Chirino
ALSO via a different API call. I'm just saying in general, to
continue to keep things simple, the first value of the repeated array
should be the one returned when the application requests a single
value for a header.
Ian Eccles
http://groups.google.com/group/stomp-spec/browse_thread/thread/1aaa20ecd9ad599e
If there is a real need for encoding complex data structures (anything
other than simple strings, really) within the headers, and the plan is
to codify this into a 2.0 spec, any changes we institute in the 1.1
spec regarding multiple headers should make the transition to the 2.0
spec easier.
Given some of the other discussions I've been seeing (particularly
encoding non-ASCII characters in headers, and the aforementioned
collections/lists/etc in headers) it seems that there are plenty of
people who feel that headers need to be extended a bit. So, I'm
recanting. Suppose the 2.0 spec allows for JSON-style header
encoding, and the 1.1 spec allows repeated headers to represent
updates to state information as well as arrays. Then, implementations
migrating from the 1.1 spec to the 2.0 spec have to deal with two
different representations of arrays/lists, and then have to know
whether it is truly a list, or an update to state information.
Further, repeated headers provides a representation of an array, or
possibly a stack/queue if order is significant, but can't easily
represent other collections (hashes, trees, etc) whereas a JSON-style
serialization can cover all of these cases.
To summarize, while I personally feel using repeated headers to cover
both use cases is in the spirit of the STOMP 1.0 specification, I
think using them to represent lists/arrays now will pose more problems
when migrating to future specifications. So I'm in favor of using
them now only to maintain a history of state changes and working
towards finding some other generic collection representation that
isn't restricted to just lists.
Ian Eccles
pulling the stack for code that is 1.1 aware.
Hiram Chirino
Lionel Cons
> To summarize, while I personally feel using repeated headers to cover
> both use cases is in the spirit of the STOMP 1.0 specification, I
> think using them to represent lists/arrays now will pose more problems
> when migrating to future specifications. So I'm in favor of using
> them now only to maintain a history of state changes and working
> towards finding some other generic collection representation that
> isn't restricted to just lists.
This makes sense.
I vote for:
- JSON and more complex header structures in 2.0 only
- 1.1 to clearly specify how to handle repeated headers
(error, keep first or keep last)
- 1.1 to clarify character encoding in the header
Cheers,
Lionel
Dejan Bosanac
--
Dejan Bosanac - http://twitter.com/dejanb
Open Source Integration - http://fusesource.com/
ActiveMQ in Action - http://www.manning.com/snyder/
Blog - http://www.nighttale.net
Ian Eccles
On Jun 18, 3:01 am, Dejan Bosanac <de...@nighttale.net> wrote:
> I agree with Lionel's approach:
>
> - JSON for 2.0
> - clarification of repeated headers in 1.1 (where I support Hiram's approach
> - keep first)
> - clarification of character encoding in 1.1
>
> Cheers
> --
> Dejan Bosanac -http://twitter.com/dejanb
>
> Open Source Integration -http://fusesource.com/
> ActiveMQ in Action -http://www.manning.com/snyder/
Hiram Chirino
the 1.1 spec.. Thanks for the input everyone.
--