Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

This

...

page

...

contains

...

a

...

wish-list

...

for

...

version

...

1.1

...

of

...

the

...

Stomp

...

protocol.

...

Please

...

feel

...

free

...

to

...

add

...

things

...

you

...

see

...

missing

...

in

...

the

...

current

...

Stomp

...

specification.

...

This

...

list

...

will

...

grow

...

into

...

a

...

final

...

1.1

...

specification

...

over

...

time.

...

For

...

any

...

discussion,

...

please

...

join

...

some

...

of

...

our

...

Mailing

...

Lists

Message NAK

There's

...

no

...

explicit

...

way

...

to

...

NAK

...

a

...

message

...

(i.e.

...

indicate

...

that

...

processing

...

that

...

message

...

failed).

...

See

...

http://old.nabble.com/un-ack-%28i.e.-indicate-message-failure%29--td16422072.html

...

Receive verb

"Store

...

and

...

forward"

...

is

...

a

...

common

...

use

...

case

...

for

...

async

...

messaging

...

that's

...

difficult

...

to

...

satisfy

...

with

...

the

...

current

...

protocol:

...

collect

...

messages

...

in

...

a

...

queue,

...

eventually

...

a

...

client

...

connects,

...

requests

...

messages

...

until

...

the

...

queue

...

is

...

empty,

...

and

...

then

...

disconnects.

...

Adding

...

a

...

"receive"

...

verb

...

to

...

the

...

protocol

...

would

...

satisfy

...

this

...

requirement.

...

It

...

would

...

use

...

the

...

same

...

headers

...

as

...

the

...

"subscribe"

...

verb

...

but

...

would

...

return

...

immediately

...

with

...

either

...

a

...

message

...

or

...

an

...

indication

...

that

...

there

...

weren't

...

any

...

messages.

...

proposed

...

by:

...

toby

...

at

...

caboteria

...

dot

...

org

Wire format negotiation

We need wire format negotiations in order to make clients and brokers understand each other on what version of the protocol will be used. I think the best place to achieve this is during the connection procedure.

The client can include the version header into the CONNECT command frame, indicating the highest version of the protocol it supports. If there is no version header, version 1.0 is assumed (supports backward compatibility).

The server responds with CONNECTED frame and it can also include the version header, which also indicates the highest version of the protocol implemented. The lack of the version header assumes version 1.0.

Now since both the client and the server knows capabilities of each other, they can use the highest version they both support.

A few examples:

Code Block
CONNECT
login: <username>
passcode: <passcode>
version: 1.1

^@

CONNECTED
session: <session-id>
version: 1.1

^@
{code}

version

...

1.1

...

will

...

be

...

used.

...

}
Code Block
CONNECT
login: <username>
passcode:<passcode>
version: 1.1

^@

CONNECTED
session: <session-id>

^@
{code}

version

...

1.0

...

will

...

be

...

used.

...

JSON

...

basic

...

type

...

notation

...

for

...

header

...

values

...

Currently

...

header

...

values

...

are

...

interpreted

...

as

...

plain

...

String,

...

which

...

makes

...

usage

...

of

...

selectors

...

with

...

numerical

...

values

...

impossible

...

with

...

Stomp.

...


The

...

idea

...

is

...

to

...

support

...

following

...

notation

...

for

...

header

...

values:

...

  • Number

...

  • (integer,

...

  • real,

...

  • or

...

  • floating

...

  • point)

...

  • String

...

  • (double-quoted

...

  • Unicode

...

  • with

...

  • backslash

...

  • escapement)

...

  • Boolean

...

  • (true

...

  • and

...

  • false)

...

  • Array

...

  • (an

...

  • ordered

...

  • sequence

...

  • of

...

  • values,

...

  • comma-separated

...

  • and

...

  • enclosed

...

  • in

...

  • square

...

  • brackets)

...

  • Object

...

  • (collection

...

  • of

...

  • key/value

...

  • pairs,

...

  • comma-separated

...

  • and

...

  • enclosed

...

  • in

...

  • curly

...

  • brackets)

...

  • null

Message transformation

We should include "message transformation" feature (implemented in ActiveMQ already, unfortunately not documented well), which allows you to do transformation of frame content to object, map or byte messages according to the transformation header provided. Currently, support for XML and JSON encoding
is supported with the following values (jms-byte, jms-object-xml, jms-object-json, jms-map-xml, jms-map-json) of the transformation header.

So for example, the following command

Code Block
SEND
destination:/queue/TEST.Q
transformation:jms-map-xml

<map>
  <entry>
    <string>name</string>
    <string>Dejan</string>
  </entry>
  <entry>
    <string>city</string>
    <string>Belgrade</string>
  </entry>
</map>

^@
{code}

would

...

send

...

a

...

map

...

message

...

to

...

the

...

queue.

...

Message

...

types

...

Allow

...

a

...

consumer

...

to

...

consume

...

different

...

types

...

of

...

messages.

...

Message

...

transformation

...

allows

...

consumer

...

to

...

subscribe

...

with

...

certain

...

type

...

of

...

transformation,

...

after

...

which

...

it

...

will

...

expect

...

only

...

one

...

type

...

of

...

messages

...

(text,

...

object,

...

map

...

or

...

byte).

...

We

...

should

...

add

...

one

...

more

...

optional

...

header

...

to

...

MESSAGE

...

command

...

called

...

message-type

...

.

...

This

...

header

...

can

...

have

...

the

...

same

...

values

...

as

...

transformation

...

header

...

used

...

on

...

SEND

...

and

...

SUBSCRIBE

...

commands,

...

jms-object-xml

...

for

...

example.

...

This

...

header

...

value

...

instructs

...

the

...

broker

...

to

...

do

...

the

...

appropriate

...

transformation,

...

even

...

if

...

it

...

is

...

not

...

specified

...

by

...

transformation

...

header.

...

Also,

...

the

...

broker

...

can

...

automatically

...

transform

...

messages

...

sent

...

with

...

"native"

...

JMS

...

clients

...

and

...

consumed

...

by

...

Stomp

...

consumers.

...

This

...

header

...

can

...

also

...

help

...

Stomp

...

consumers

...

to

...

determine

...

the

...

type

...

of

...

the

...

message,

...

if

...

they

...

are

...

consuming

...

from

...

destinations

...

that

...

contains

...

multiple-type

...

messages.

...

Content

...

encoding

...

(stomp

...

1.0

...

supports

...

binary

...

messages,

...

that

...

is

...

the

...

very

...

reason

...

there

...

is

...

a

...

content-length

...

header)

Support content-encoding

...

header

...

for

...

SEND

...

and

...

SUBSCRIBE

...

commands

...

allowing

...

to

...

send

...

gziped

...

and

...

base64

...

encoded

...

content.

...

I

...

would

...

prefer

...

to

...

send

...

and

...

receive

...

binary

...

messages

...

as

...

base64

...

encoded

...

text,

...

since

...

it

...

seems

...

more

...

natural

...

to

...

me

...

for

...

this

...

kind

...

text-based

...

protocol.

...

Again,

...

this

...

introduces

...

the

...

concept

...

of

...

binary

...

message

...

to

...

Stomp

...

protocol,

...

which

...

I'm

...

not

...

sure

...

we

...

want

...

to

...

do.

...

But

...

surely,

...

gziped

...

content

...

would

...

be

...

appreciated

...

in

...

many

...

contexts.

...

Optional

...

Keep

...

Alive

...

protocol.

...

Right

...

now

...

we

...

have

...

to

...

depend

...

on

...

the

...

OS

...


to

...

detect

...

socket

...

failure

...

to

...

time

...

out

...

a

...

dead

...

client.

...

Would

...

be

...

nice

...

if

...


the

...

client

...

could

...

optionally

...

agree

...

to

...

send

...

a

...

Keep

...

Alive

...

commands

...

when

...


the

...

connection

...

is

...

idle.

...

That

...

way

...

the

...

sever

...

can

...

detect

...

dead

...

clients

...


quicker.

...

Virtual

...

hosting

...

Perhaps

...

standardize

...

a

...

'host'

...

header

...

in

...

the

...

CONNECT

...

frame

...

to

...

specify

...


the

...

host

...

name

...

that

...

the

...

client

...

is

...

connecting

...

to.

...

This

...

would

...

allow

...


implementing

...

virtual

...

hosting

...

where

...

multiple

...

DNS

...

host

...

entries

...

point

...

at

...


the

...

same

...

STOMP

...

server.

...

Individual

...

acks

...

(this

...

comment

...

must

...

refer

...

to

...

an

...

older

...

version

...

of

...

the

...

spec,

...

since

...

the

...

v1.0

...

protocol

...

does

...

specify

...

a

...

required

...

message-id

...

header

...

that

...

indicates

...

which

...

message

...

is

...

being

...

acked)

...

The

...

Stomp

...

specs

...

at

...

http://stomp.codehaus.org/Protocol

...

does

...

not

...

detail

...

the

...

ack

...

behavior

...

nor

...

does

...

it

...

recommend

...

or

...

hint

...

anything.

...

Introduce

...

a

...

new

...

ack

...

mode

...

in

...

Stomp

...

SUBSCRIBE

...

header:

...

The

...

chosen

...

header

...

is

...

called

...

'client-individual';

...

to

...

reflect

...

that

...

ACKs

...

are

...

still

...

client

...

initiated

...

PLUS

...

"individual"

...

to

...


declare

...

that

...

the

...

client

...

intends

...

to

...

acknowledge

...

individual

...

messages

...

by

...

message-id,

...

not

...

in

...

batches

...

as

...

with

...

simple

...

'client'

...

ack

...

mode.

...

Kindly

...

suggest

...

a

...

another

...

header

...

name

...

if

...

you

...

can

...

think

...

of

...

a

...

more

...

appropriate

...

one.

...

PING

Ping just verifies that the server is alive. The server should respond with "Pong" to indicate that it is indeed there.