Thu Jan 15 11:08:04 CET 2009
Hi Steve & others,
| Despite the fact that UBF seems to have been rather inactive
| development-wise for 5 years, it really does look to me like
| it's the right solution for us (a large amount of small
| messages, various client platforms/technologies).
I think it is.
| So I'm wondering...
| * Does anybody have experience of using UBF?
We use it in our (research) department as the prefered protocol/encoding
for communicating with applications on mobile phones (J2ME). The server
is either Erlang or Java.
We do not use the contract part a lot, since we do not have Java support
for it. We especially like the simple encoding rules and that we have
implementations for Erlang, J2SE and J2ME.
It is also very nice to send over binaries with UBF, since they do not
need to be base64 or otherwise encoded.
| * Was this experience of using UBF 100% positive?
I cannot remember any negative experiences. Since the source is
available, we were able to modify some stuff to our liking. E.g. we
decoupled the socket setup from the server/client role: the socket may
be set up by the UBF server. We needed to retrieve information from the
mobile, so it should be UBF server. On the other hand, we cannot set up
a TCP connection from the mobile, so we the mobile (i.e. UBF server)
sets up the connection. We break some rules this way, but it works.
| * Can anyone think of any downside to using UBF over XML/WSDL
| (apart from the obvious cultural ones)?
There is no code generation for UBF. You cannot generate UBF specs from
code either. With UBF in Java you have to unpack the messages by hand,
you do not have a generated class per message. Now that I write this, I
guess it would be possible to generate code from the contract, only
nobody has done that as far as I know.
With UBF you have to encode floats into some structure yourself, since
UBF does not support floats.
More information about the erlang-questions