Openwire does use an Object to number mapping for some constructs -
notably destinations etc - though this does not extend to the level
you're thinking of .
This could be an interesting additional capability - is that
something you think you could help contribute ?
cheers,
Rob
On Jul 17, 2007, at 4:20 AM, huntc wrote:
Hi there,
I've started encoding XML messages with MapMessage objects. To do
this I use
the name of the map to provide an Xpath expression into the
document that
the value represents e.g. a name might be:
"/j:FeatureCollection/featureMembers/j:Flight/track/j:JourneyStatus/
validtime/TimeInstant/timePosition"
The benefit of this approach is that:
(i) the client/server code is readable; and
(ii) an XML document can be reconstructed by the client.
In the interests of efficiency I'm thinking of representing the Xpath
expression numerically to reduce it to a 32 bit number - possibly
using
Java's String hashCode method to generate it. Thus a hex string
name could
be something like "0F1C3D4A" i.e. 8 UTF-8 characters. Naturally one
has to
consider possible duplicate hash keys for different string
values... that
shouldn't be a big issue though.
This got me thinking - I started to wonder whether there had ever
been any
consideration for efficiently passing map messages with Openwire
(more so
than it presently does of course). What I'm thinking is that
Openwire could
provide a map key name -> number translation of known keys upon a
client
first requesting/subscribing to a queue/topic respectively. For new
keys
that are published the protocol could update its translation table
and also
send out the new translation information to the client.
As I recall from my Tuxedo days, key name elements were passed as
numbers
and each client had to #include that mapping. Naturally if that number
scheme was updated then it could break each client. Thus my
thinking on
hashing the key name so that their values are more resilient to
keys being
added or removed.
Is the incorporation of hashing map message key values something
that has
been thought out before?
Indeed, is this something that should be exposed at the JMS level -
perhaps
a HashKeyMapMessage class...
Cheers,
-C
--
View this message in context: http://www.nabble.com/Greater-
Openwire-MapMessage-efficiency-tf4094367s2354.html#a11642343
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
