records generated from UBF

[Erik Pearson]

After a little more fiddling around, I have a practical question about 
UBF(A):

The representation of a "binary" type is:

   Int ~blahblah~

Where Int is an integer, and ~ is the delimiter for the binary data, 
and blahblah is a stream/array of bytes Int long (and the space is 0 or 
more spaces)

In order resolve the ambiguity with regular Int , the otherwise simple 
parsing becomes more complicated. It seems to me, unnecessarily 
complex. That is, the parser first determines that there is an int, and 
then it has to keep going to determine whether it really is an int or 
whether it will become a binary.

What if the binary representation was something like

   ~ Int ~blahblah~

Then the initial ~ would be a nice and and simple flag for the parser 
that binary value was coming up. This would be consistent with all of 
the other simple types, for which the initial byte serves as a flag for 
the type (" for string, ' for contants, 0-9 or - for number (oops, or 
binary)...)

Finally, just a quick correction to the spec at

http://www.sics.se/~joe/ubf/site/ubfa.html

I believe the structure should be defined with comma separators rather 
than just whitespace

     { Obj1, Obj2, ..., Objn }

rather than

     { Obj1 Obj2 ... Objn }

The examples show the comma separators.

Thanks,

Erik.


On Wednesday, April 16, 2003, at 09:18 AM, Erik Pearson wrote:

> Thanks Ulf,
>
> I hadn't actually looked for the java stuff in the download, since it 
> the java section of the site says that it is not done yet! Well, there 
> it is!
>
> It works fine so far.
>
> FWIW, this is probably what how I'll attempt to use it first -- What 
> I'm doing is integrating it into my web server scripting language (a 
> very close offshoot of Tcl, from the Jacl tcl implementation, that is, 
> Tcl implemented in Java). I'm starting with just UBF(A), since for my 
> purposes gettting two or more disparate network services (web or 
> other) to exchange information is the first goal. The first bit of 
> work will be to implement a pleasant java/tcl interface so that UBF(A) 
> can be easily scripted on the web server. Since UBF(A) is 
> straightforward, that part should be pretty easy, and is mostly 
> working now. After that, UBF(B)...
>
> On the other side of the equation are several other related network 
> services or applications which  are variously implemented (currently) 
> in Tcl and CL. Now, the discovery of UBF has prompted me to rethink 
> the usage of Erlang for these same services. (I had been using Erlang, 
> but issues with mnesia caused me to put it aside for a while...)
>
> BTW, the very practical and straightforward nature of UBF fits right 
> into why Erlang has always been so appealing (to me.)
>
> I'll check back later (after my very short vacation) in if I get some 
> interesting results.
>
> Thanks,
>
> Erik.
>
>
> On Tuesday, April 15, 2003, at 01:43 AM, Ulf Wiger wrote:
>
>> On Tue, 15 Apr 2003, Erik Pearson wrote:
>>
>>> I'd like to give UBF a try. It looks really great, and
>>> thanks for your addition to it.
>>
>> Good. (:
>>
>> Joe is, I believe, in Iceland this week, undoubtedly
>> spending quality time trying out all the hot baths there.
>> Let's see how he wants to play it when he gets back.
>> Otherwise, you can certainly download whatever he has made
>> available on his website, and I can send you my modified
>> version, with absolutely no guarantees. ;-)
>>
>>
>>> What would be great, though, is if someone can share a Java
>>> implementation (or any other implementation out there, e.g.
>>> Tcl). I need it to glue together a Java servlet to Erlang
>>> (or whatever).
>>>
>>> From the UBF paper, it appears that a Java implementation
>>> was largely completed. It would be great to either use that
>>> code, or start with it and complete the implementation far
>>> enough to get something working.
>>
>> There are two Java implementations that I know of. Luke's
>> Java client that's included in Joe's care package, and Jon
>> Åkergården's Athletics client prototype. Jon's Java code can
>> be downloaded from http://www.it.kth.se/~e98_jak/
>> However, Jon is actively working on the code right now, so
>> the downloadable version is almost certainly outdated.
>>
>>> From a quick glance (and be warned: I've yet to write even
>> Hello World in Java), Luke's UBF decoder seems to lack
>> caching support(*), and Jon's decoder lacks support for
>> binaries; I'm also unsure about whether Jon's decoder
>> handlers escaping properly, but Luke's does.
>>
>> If you take the union of the two, you probably have a
>> complete decoder, but they don't seem totally compatible to
>> me.  ;)  Someone else with more knowledge of Java will
>> perhaps see things differently.
>>
>> /Uffe
>>
>> (*) This is only a problem if the other side uses caching.
>> Joe's Erlang-based UBF encoder will take advantage of
>> caching, so a corresponding decoder will of course have to
>> as soon as there is something cachable in the messages.
>>
>> -- 
>> Ulf Wiger, Senior Specialist,
>>    / / /   Architecture & Design of Carrier-Class Software
>>   / / /    Strategic Product & System Management
>>  / / /     Ericsson AB, Connectivity and Control Nodes
>>
>>
> Erik Pearson
> Adaptations
> desk +1 510 527 5437
> cell +1 510 517 3122
>
>
Erik Pearson
Adaptations
desk +1 510 527 5437
cell +1 510 517 3122