RE: POE::Component::Client::Stomp
Kevin Esteb
The reason it won't work is that these modules use the "bytes_message" member of the Net::Stomp::Frame object, this indicates wither the Stomp frame is binary or not. This is undocumented and is stripped from any outgoing frames. Setting this when creating a frame inserts a "content-length" header, and when receiving a frame, it is set if a "content-length' header is present. This member is Boolean. This is a integral part of the above code and would not be easy to rewrite.
-----Original Message-----
From: Lionel Cons [mailto:lione...@gmail.com]
Sent: Friday, February 19, 2010 4:38 AM
To: Kevin Esteb
Subject: Re: POE::Component::Client::Stomp
2010/2/16 Kevin Esteb <kes...@wsipc.org>:
> POE::Filter::Stomp is also being used by POE::Component::Server::MessageQueue. Have you sent anything to David Snopek?
Yes, I contacted him too.
> I believe that POE::Component::Client::Stomp is also being used by POE::Component::Server::AysncEndPoint. Have you sent anything to Alejandro Imass?
No, not yet.
> Are you keeping the same API as Net::Stomp?
No. Although they are very similar, the two APIs are different. The
transition should however be easy.
> I only did a brief overview of your stuff, but due to the nature of CPAN, I don't know how many other people are actually using my stuff. So an API change may not 'sit' very well.
For users of your modules, this should hopefully be near transparent.
You can simply change from the old STOMP module to the new one in one
of your next releases and behind the scene a new dependency will
appear, like if you want to use another CPAN module...
Cheers,
Lionel
Kevin Esteb
There is no need for "content-length" if there are no null bytes within the frame. The spec quite clearly says that you read the data stream until the null byte or to "content-length" when specified. I also agree that including "content-length" is a good thing, but it is not required. Remember the old adage "be lenient in what you receive and strict in what you send".
I can not use Net::STOMP::Frame as it is currently stands. I can not arbitrarily change my API to accommodate your changes. When you take over the maintence of somebody else's code you inherit the baggage of that code.
As it stands there is a body of code the depends on the behavior of Net::Stomp::Frame. If you replace this code, you need to support its API. This includes the "bytes_message" hack and also the parse() and to_string() methods. My code only depends on the command(), header(), and body() methods along with the "bytes_message" hack, but others may not.
-----Original Message-----
From: Lionel Cons [mailto:lione...@gmail.com]
Sent: Tuesday, February 23, 2010 4:21 AM
To: Kevin Esteb
Subject: Re: POE::Component::Client::Stomp
2010/2/22 Kevin Esteb <kes...@wsipc.org>:
> The reason it won't work is that these modules use the "bytes_message" member of the Net::Stomp::Frame object, [...]
Yes, I know about this hack...
STOMP has no notion of binary versus non-binary frames. In fact, the
protocol specification recommends to always include the content-length
header. The protocol spec (http://stomp.codehaus.org/Protocol)
contains: "It is recommended that SEND frames include a content-length
header which is a byte count for the length of the message body".
OTOH, ActiveMQ uses this field to map a STOMP message to a JMS message
(as per http://activemq.apache.org/stomp.html) and indeed one may need
to omit the content-length header.
My module follows the protocol spec by default, i.e. all frames with a
body include a content-length header. However, if you want to omit
this header, you can. In my current code (not yet in CPAN), you can
achieve this by setting the content-length header to the empty string,
which simply means "omit the content-length header when building the
frame byte stream".
So, in conclusion, the API is different but you can still control the
inclusion of the content-length header in a built frame.
Cheers,
Lionel
Kevin Esteb
I wrote my code for much the same reasons that you wrote yours. The Net::Stomp environment didn't work for my needs.
Maybe the various interested parties can get together and create a unified approach to the STOMP protocol within Perl. For example the frame parser in POE::Filter::Stomp is a vetted chunk of code that has processed millions of frames without any problems. All it requires is a buffer to work.
-----Original Message-----
From: Lionel Cons [mailto:lione...@gmail.com]
Sent: Wednesday, February 24, 2010 4:20 AM
To: Kevin Esteb
Subject: Re: POE::Component::Client::Stomp
2010/2/23 Kevin Esteb <kes...@wsipc.org>:
> When you take over the maintence of somebody else's code you inherit the baggage of that code.
Kevin,
Please allow me to give you a bit of context.
In the project I'm responsible for, we need a reliable STOMP library
for Perl. This is for a production environment, with real data being
transferred.
We initially tried Net::Stomp but detected some bugs and missed some
features, like SSL support. We tried to contact the author and he did
not reply. We then saw both extensions (e.g. Net::Stomp::Receipt) and
forks (e.g. on github) of the code base which is on CPAN.
Since we could not rely on different bits of code gathered from
different places and since the amount of code needed to rewrite
Net::Stomp was small, we simply rewrote it from scratch, with emphasis
on reliability. We use this new code now and do not see anymore the
problems we had with Net::Stomp.
Instead of keeping the code for ourselves, we decided to put it on
CPAN. The intent was not to replace Net::Stomp but to offer an
alternative implementation that people could decide to use, or not.
The clash with the module name (Net::Stomp vs Net::STOMP) created some
problems and the Net::Stomp author recently offered me to take over
Net::Stomp, something that I did not ask for. If this creates a
problem, I can still decline his offer.
We will continue with our code base, using a module name different
from Net::Stomp. If some people want to use our code, fine, we will
support them. If others want to stay with Net::Stomp, fine too.
Cheers,
Lionel