records generated from UBF

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

records generated from UBF

Ulf Wiger-4

Is anybody else out there playing around with UBF?

I wrote a small utility yesterday that generates a .hrl file
from a UBF specification. It generates a record
specification for each type that looks like a tagged tuple,
where the tag matches the type name, and all other
elements are type references. For example:

  person() = {person, name(), age(), address(), phone()};

becomes

  -record(person, {name, age, address, phone}).

The UBF contract checker will type check all incoming and
outgoing messages, so you can trust that all attributes of a
record are type correct.

This makes it quite easy to put together external interfaces
with a very nice programming style for the back-end.

...

I will take the opportunity to extoll the virtues of
UBF-oriented programming by providing a "small" example.


The server in question handles administrative tasks for a
Track & Field competition, and also serves spectators with
updates on what is going on (which, as everyone who's been
to a Track&Field event knows, is quite a lot).

The network is typically WLAN. The client is written in
Java, and the server in Erlang. I use UBF, mnesia, rdbms,
and will probably later use xmerl, inets and perhaps
erlguten. Who knows - maybe we'll throw in sowap
as well. ;) This is an Open Source project.

The UBF contract specifies some basic types, e.g.

club_id()               = constant();
location()              = string();
club()                  = {club, club_id(), name(),
                           location(), info()};

Using the utility described above, "compiling" the contract
results in, among other things, a .hrl file with record
declarations to match:

-record(club, {club_id,
               name,
               location,
               info}).

The contract also specifies valid messages:

qNewClub()              = {new_club, club()};
qListClubs()            = list_clubs;
rListClubs()            = club_list() | rError();
qOpenClub()             = {open_club, club_id()};
rOpenClub()             = club() | rError();
qControlClub()          = {control_club, club_id()};
qEndControlClub()       = {end_control_club, club_id()};
qUpdateClub()           = {update_club, club()};
qDeleteClub()           = {delete_club, club_id()};

And two states, 'administrator' and 'viewer', where valid
messages are listed:

+STATE administrator
        ...
        qNewClub()      => rReply() & administrator;
        qControlClub()  => rReply() & administrator;
        qEndControlClub() => rReply() & administrator;
        qUpdateClub()     => rReply() & administrator;
        qDeleteClub()     => rReply() & administrator;
        ...

(actually, messages valid both for 'administrator' and
'viewer' are listed under ANYSTATE:)

+ANYSTATE
        qListClubs()    => rListClubs();
        qOpenClub()     => rOpenClub();


I have one plugin serving both administrators and viewers,
since the viewer information is a subset of the
administrator information. I start two instances of the
plugin, one in 'administrator' state and one in 'viewer'
state. After this, the contract checker makes sure that only
messages valid for each state are admitted, and I don't
have to worry much about checking stuff in my own code.

The code in the plugin looks like this:

========

handlerRpc(S, list_clubs, D, Env) ->
    reply(catch {{club_list, club:list_clubs()},
          S, D}, S, D);

handlerRpc(S, {open_club, ClubId}, D, Env) ->
    reply(catch {club:open(ClubId), S, D}, S, D);

handlerRpc(S, {new_club, Club}, D, Env) ->
    reply(catch {club:new(Club), S, D}, S, D);

========

And the code in the different modules (club, athlete, event,
etc.) looks sort of like this:

========

-module(cath.server.club).

-export([list_clubs/0,
         new/1,
         open/1,
         update/1,
         delete/1]).

-export([schema/1]).

-include("cath_plugin.hrl"). % generated .hrl file


schema([]) ->
    [
     {club, [{attributes, record_info(fields, club)},
             {record_name, club},
             {disc_copies, db:writer_nodes()},
             {ram_copies, db:reader_nodes()}]}
    ].

list_clubs() ->
    db:list_items(club).

new(#club{club_id = Id} = Club) ->
    db:new(club, Id, Club).

open(ClubID) ->
    db:open(club, ClubID).

update(#club{club_id = Id} = Club) ->
    db:update(club, Id, Club).

delete(Id) ->
    db:delete(club, Id).


The db.erl module is a database wrapper, which uses rdbms as
the activity module. Rdbms makes sure e.g. that one cannot
add an athlete to a non-existant club, or that all athletes
belonging to a club are deleted if the club is deleted --
basic referential integrity, that is.

Error handling is simple. Each user gets a session (a
process). UBF will exit and close the session if the
protocol is violated, and mnesia/rdbms will abort and exit
if anything goes wrong inside a transaction; transaction
aborts lead to error messages. If the protocol doesn't allow
for an error message in response to a certain query, it will
complain, and close the session. Perhaps not the most
elegant way to do it, but it works.

A more complex module, e.g. athlete, might have to handle
dependencies:

========

-module(cath.server.athlete).

-export([list_athletes/1,
         open/2,
         new/2,
         update/2,
         delete/2]).

-export([schema/1]).

-include("cath_plugin.hrl").


schema(Contest) ->
    TabName = contest:table_name(athlete, Contest),
    [
     {TabName,
      %% mnesia options
      [
       {disc_copies, db:writer_nodes()},
       {ram_copies, db:reader_nodes()},
       {attributes, record_info(fields, athlete)},
       {record_name, athlete}
      ],
      %% rdbms properties
      [
       %% when deleting a club, also delete its athletes
       {{attr, {club, club_id}, references},
        [{TabName,club,{full,cascade,ignore}}]},
       {{attr, {TabName,club}, references},
        [{club, club_id, {full,ignore,no_action}}]}
      ]
     }
    ].

list_athletes(Contest) ->
    lists:map(
      fun(#athlete{club = Id} = A) ->
              A#athlete{club = club:open(Id)}
      end, db:list_items(athlete, Contest)).


new(#athlete{athlete_id = Id} = Ath, Contest) ->
    db:new(athlete, Id, Ath, Contest).

========

That is, the referential integrity checks done by rdbms
ensure that the new athlete actually belongs to an existing
club, and UBF has already checked that the #athlete{} record
contains valid types.

Not all functionality has been implemented yet, but the
server runs all day during testing, and it never crashes
(of course, it's Erlang).

Performance? I haven't tested it yet, but I'm sure it's more
than sufficient. The application is designed to take
advantage of distribution, if I add a load sharing front-end
to it (I vaguely recall this having been done before...;)


Life is good.

/Uffe

--
Ulf Wiger, Senior Specialist,
   / / /   Architecture & Design of Carrier-Class Software
  / / /    Strategic Product & System Management
 / / /     Ericsson AB, Connectivity and Control Nodes


Reply | Threaded
Open this post in threaded view
|

records generated from UBF

Erik Pearson-2
I'd like to give UBF a try. It looks really great, and thanks for your
addition to it.

I'm currently need to move from a simple data exchange format that I've
used for years (it is a glorified url query string), and have stayed
away from XML-RPC and the ilk partly because of the reasons sited at
the UBF site (http://www.sics.se/~joe/ubf). UBF just may save the day!

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.
Yeah, call me a moocher :)

Thanks,

Erik.


On Tuesday, April 8, 2003, at 01:50 AM, Ulf Wiger wrote:

>
> Is anybody else out there playing around with UBF?
>
> I wrote a small utility yesterday that generates a .hrl file
> from a UBF specification. It generates a record
>

[ all the good stuff snipped... ]

>
>
> Life is good.
>
> /Uffe
>
> --
> Ulf Wiger, Senior Specialist,
>    / / /   Architecture & Design of Carrier-Class Software
>   / / /    Strategic Product & System Management
>  / / /     Ericsson AB, Connectivity and Control Nodes
>

Erik Pearson
Adaptations



Reply | Threaded
Open this post in threaded view
|

records generated from UBF

Mickael Remond-2
Erik Pearson <erik> writes:

> 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. Yeah, call me a moocher :)

UBF Java implementation is available in the latest archive from the
downloads area:

http://www.sics.se/~joe/ubf/downloads/ubf-1.11.tgz

--
Micka?l R?mond
http://www.erlang-projects.org/



Reply | Threaded
Open this post in threaded view
|

records generated from UBF

Ulf Wiger-4
In reply to this post by Erik Pearson-2
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



Reply | Threaded
Open this post in threaded view
|

records generated from UBF

Luke Gorrie-3
Ulf Wiger <etxuwig> writes:

> 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.

At the last Erlang conference Joe mentioned that somebody in New
Zealand had also done a Java implementation. I think he said it
included a contract-checker and everything. I don't know if it's
available, or if my memory is failing me.

I haven't looked at Jon's code, but I guess it's more up-to-date than
mine, having been used in a real system. So I'll assume nobody needs
any new features in my Java client unless I hear otherwise.

Cheers,
Luke



Reply | Threaded
Open this post in threaded view
|

records generated from UBF

Erik Pearson-2
In reply to this post by Ulf Wiger-4
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



Reply | Threaded
Open this post in threaded view
|

records generated from UBF

Erik Pearson-2
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



Reply | Threaded
Open this post in threaded view
|

records generated from UBF

Ulf Wiger (AL/EAB)
From: "Erik Pearson" <erik>

> 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)...)

I'm not the one to either approve or reject your suggestion, but I think
you do have a good point.

> 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.

I was also confused by the example, but... reading on you will find that
Joe has defined comma as whitespace:

"For convenience blank, carriage return, line feed tab and comma are treated
as white space. Comments can be included in UBF(A) with the syntax %...% the
usual quoting convention applies. "

That is, the commas are optional.

/Uffe



Reply | Threaded
Open this post in threaded view
|

records generated from UBF

Erik Pearson-2
Thanks, Ulf ...

some comments below

>
>> 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.
>
> I was also confused by the example, but... reading on you will find
> that
> Joe has defined comma as whitespace:
>
> "For convenience blank, carriage return, line feed tab and comma are
> treated
> as white space. Comments can be included in UBF(A) with the syntax
> %...% the
> usual quoting convention applies. "
>
> That is, the commas are optional.

Thanks, I didn't notice the comma sneaking in there as whitespace.
However, I am still somewhat concerned:

- how do you disambiguate {"Hi" 'greeting', "world" 'planet'}? It seems
that this could be either {Obj1 Obj2 Obj3 Obj4} or {Obj1 Obj3 Obj4} or
{Obj1 Obj2}.

I must be missing something crucial here.

I have a new concern too -- how to represent null (i.e. missing, blank)
values?
For strings it would be
"" $

for constants
'' $

for binary
0 ~~ $

(or
~0~~ $
if the tilde prefix is preferable),

but for integers it would be

  $

.. that is, a blank. But this raises a few issues:

1. How do you carry the type information for a blank integer?

2. Is there a valid concept of typeless null? That is not only is the
value blank, but it also carries not type information?

3. It seems impossible to represent a null tagged integer -- it would
be indistinguishable from a plain constant.

Do you or does anyone else have experience with confronting these
issues?

I can see that UBF(B) might help with some of these issues, since the
usage of values within a particular context would imply their type.
However, at this point I'm just concerned with getting plain old UBF(A).

Also, one of the things I'm trying to keep an eye on is places where
the spec introduces more work for the parser-builder. In my case, I
would like to use this with multi-vendor data and message exchange. In
these cases, having a clear, easy-to-implement spec is very important.
People need to implement this stuff in all sots of weird languages and
often in a hurry!

Thanks,

Erik.



>
> /Uffe
>
>
Erik Pearson
Adaptations
desk +1 510 527 5437
cell +1 510 517 3122



Reply | Threaded
Open this post in threaded view
|

records generated from UBF

Shawn Pearce
Erik Pearson <erik> wrote:
> Thanks, I didn't notice the comma sneaking in there as whitespace.
> However, I am still somewhat concerned:
>
> - how do you disambiguate {"Hi" 'greeting', "world" 'planet'}? It seems
> that this could be either {Obj1 Obj2 Obj3 Obj4} or {Obj1 Obj3 Obj4} or
> {Obj1 Obj2}.

Its clearly {Obj1 Obj2 Obj3 Obj4}.  ' ' (space) and ',' (comma) are both
whitespace characters to UBF.  Thus its {"Hi"'greeting'"world"'planet'},
which is a 4 object tuple.  Now UBF(B) may define that the atom
'greeting' represents a type which is called greeting, however a
type can only be made of up simple types.  Thus in order to create
a UBF(B) type of 'greeting' it would be necessary to encode as

{"Hi" {'greeting', "world"}, 'planet'}

which if you look at Erlang records is exactly how a greeting record
would be encoded.  (Tuple holding the tuple name as the first term
and the values as the rest. So clearly the example you give cannot
even be a UBF(B) type.

> I must be missing something crucial here.
>
> I have a new concern too -- how to represent null (i.e. missing, blank)
> values?

Use an atom.  In Erlang (which UBF has borrowed a lot from), null
is generally defined (by convention) to be the atom 'undefined'.
Thus if you want a null string or a null integer, the UDF(B) must
allow either an Int or the atom 'undefined'.  Otherwise you cannot
define a null Int.  (Same for the other types.)

> For strings it would be
> "" $
>
> for constants
> '' $
>
> for binary
> 0 ~~ $
>
> (or
> ~0~~ $
> if the tilde prefix is preferable),
>
> but for integers it would be
>
>  $
>
> .. that is, a blank. But this raises a few issues:
>
> 1. How do you carry the type information for a blank integer?
>
> 2. Is there a valid concept of typeless null? That is not only is the
> value blank, but it also carries not type information?

Yes, the atom 'undefined' does this by convention, but this of course
means you cannot use the atom 'undefined' to mean a non-typless-null
value.  :)  It sounds ugly, but in practice it works better than say
the typeless SQL null.

> 3. It seems impossible to represent a null tagged integer -- it would
> be indistinguishable from a plain constant.

Erlang has no concept of a null integer, it uses 'undefined' (by
convention).  You could define the atom 'null' or 'nullint' or 'nan'
to mean the same thing(s), but its your code that must define the
meaning of these atoms.  I much prefer the Erlang system of doing it
by convention, rather than forcing it on you.

> Do you or does anyone else have experience with confronting these
> issues?
>
> I can see that UBF(B) might help with some of these issues, since the
> usage of values within a particular context would imply their type.
> However, at this point I'm just concerned with getting plain old UBF(A).
>
> Also, one of the things I'm trying to keep an eye on is places where
> the spec introduces more work for the parser-builder. In my case, I
> would like to use this with multi-vendor data and message exchange. In
> these cases, having a clear, easy-to-implement spec is very important.
> People need to implement this stuff in all sots of weird languages and
> often in a hurry!

I'm not quite sure what you mean here.  Almost every language/system
I have worked in this far has a concept of a linked list, a concept
of an array, of a constant (atom), and numerics/strings/binaries.  Thus
you should be able to quickly read the UBF(A) spec and see the mapping
to your language environment, and just map it.  Perhaps the UBF(A) spec
just isn't clear on how one would handle null values?

One thing I like about UBF(A) is that it should only take a few days
to write a parser, while XML is estimated to take about 3 weeks.  Thus
most developers should be able to bring a UBF(A) parser online in a very
short time, perhaps about the same amount of effort required to just
write a simple SAX or DOM parser (which uses an existing parser).  :)

--
Shawn.

  When smashing monuments, save the pedstals -- they always come in handy.
  -- Stanislaw J. Lem, "Unkempt Thoughts"


Reply | Threaded
Open this post in threaded view
|

records generated from UBF

Erik Pearson-2
Hi Shawn,

Thanks for the explanations!

I think we are coming at the problem from different sides, though. I'm
trying to see this from the "Erlang talking to the outside world" point
of view, which in turn implies "the outside world talking to the
outside world". In this approach, Erlang conventions don't really
matter. What matters is the internal consistency of UBF, and its
ability to convey any type of information. At least that is what _I_
want out of it :)

 From this point of view, my comments are below:

On Monday, April 21, 2003, at 08:52 AM, Shawn Pearce wrote:

> Erik Pearson <erik> wrote:
>> Thanks, I didn't notice the comma sneaking in there as whitespace.
>> However, I am still somewhat concerned:
>>
>> - how do you disambiguate {"Hi" 'greeting', "world" 'planet'}? It
>> seems
>> that this could be either {Obj1 Obj2 Obj3 Obj4} or {Obj1 Obj3 Obj4} or
>> {Obj1 Obj2}.
>
> Its clearly {Obj1 Obj2 Obj3 Obj4}.  ' ' (space) and ',' (comma) are
> both
> whitespace characters to UBF.  Thus its
> {"Hi"'greeting'"world"'planet'},
> which is a 4 object tuple.  Now UBF(B) may define that the atom
> 'greeting' represents a type which is called greeting, however a
> type can only be made of up simple types.  Thus in order to create
> a UBF(B) type of 'greeting' it would be necessary to encode as
>
> {"Hi" {'greeting', "world"}, 'planet'}
>
> which if you look at Erlang records is exactly how a greeting record
> would be encoded.  (Tuple holding the tuple name as the first term
> and the values as the rest. So clearly the example you give cannot
> even be a UBF(B) type.

The problem is that the object

   "Hi" 'greeting' $

is a perfectly valid UBF value -- a semantically tagged string. I
believe that any base object (string, constant, integer, binary) can be
extended by adding a semantic tag after it. Thus anywhere that an
object can appear, you should be able to add a constant value after it
and have it recognized as a semantic tag. My problem is that within a
structure this doesn't seem to work unless you have a specific
byte-code for separating objects (perhaps better thought of as a way of
terminating an object).

That was the point of the example. I hope!

>
>> I must be missing something crucial here.
>>
>> I have a new concern too -- how to represent null (i.e. missing,
>> blank)
>> values?
>
> Use an atom.  In Erlang (which UBF has borrowed a lot from), null
> is generally defined (by convention) to be the atom 'undefined'.
> Thus if you want a null string or a null integer, the UDF(B) must
> allow either an Int or the atom 'undefined'.  Otherwise you cannot
> define a null Int.  (Same for the other types.)

Yeah, I guess one can say that typeless nulls (ala lisp nil or java
null) can be represented, but that typed nulls would be in the realm of
UBF(B). Either you'd need to use more structure (e.g. 'undefined'
'int32' $), or complex types in order for UBF(B) to know what you are
talking about. I guess that when you need this level of interpretation,
you should be dealing with UBF(B) anyway.

However, I do think that it is a relatively important distinction that
the UBF(A) encoding does not allow for the encoding of a null value
into its objects (with type).

>
>> For strings it would be
>> "" $
>>
>> for constants
>> '' $
>>
>> for binary
>> 0 ~~ $
>>
>> (or
>> ~0~~ $
>> if the tilde prefix is preferable),
>>
>> but for integers it would be
>>
>>  $
>>
>> .. that is, a blank. But this raises a few issues:
>>
>> 1. How do you carry the type information for a blank integer?
>>
>> 2. Is there a valid concept of typeless null? That is not only is the
>> value blank, but it also carries not type information?
>
> Yes, the atom 'undefined' does this by convention, but this of course
> means you cannot use the atom 'undefined' to mean a non-typless-null
> value.  :)  It sounds ugly, but in practice it works better than say
> the typeless SQL null.

Actually, I think that just an empty object in UBF(A) is a typeless
null. UBF(A) doesn't mention it, but it sesms like a reasonable
interpretation  that an empty object is a null object.

  $
is a null object -- no data, no type.

however, there can't be any tagged null because
  'tag' $

would be interpreted as the constant 'tag'.

What do the empty structure and list mean?
{ } $
# & $


>
>> 3. It seems impossible to represent a null tagged integer -- it would
>> be indistinguishable from a plain constant.
>
> Erlang has no concept of a null integer, it uses 'undefined' (by
> convention).  You could define the atom 'null' or 'nullint' or 'nan'
> to mean the same thing(s), but its your code that must define the
> meaning of these atoms.  I much prefer the Erlang system of doing it
> by convention, rather than forcing it on you.

Again, I'm just grappling with how to encode objects at the A level --
what can and can't be done -- using just the UBF spec as the guideline.

>
>> Do you or does anyone else have experience with confronting these
>> issues?
>>
>> I can see that UBF(B) might help with some of these issues, since the
>> usage of values within a particular context would imply their type.
>> However, at this point I'm just concerned with getting plain old
>> UBF(A).
>>
>> Also, one of the things I'm trying to keep an eye on is places where
>> the spec introduces more work for the parser-builder. In my case, I
>> would like to use this with multi-vendor data and message exchange. In
>> these cases, having a clear, easy-to-implement spec is very important.
>> People need to implement this stuff in all sots of weird languages and
>> often in a hurry!
>
> I'm not quite sure what you mean here.  Almost every language/system
> I have worked in this far has a concept of a linked list, a concept
> of an array, of a constant (atom), and numerics/strings/binaries.  Thus
> you should be able to quickly read the UBF(A) spec and see the mapping
> to your language environment, and just map it.  Perhaps the UBF(A) spec
> just isn't clear on how one would handle null values?

The problem has more to do with making sure that the mapping is as
strightforward as possible.  Also, I want as few of these questions as
possible coming my way!

Some issues that I've come across so far are:

- encoding for binaries is made a little more complex than (I think)
necessary, since there is no initial bytecode to signal the type. The
parser has to keep going past the integer to determine if the object is
an integer or a binary.

- encoding of structures seems ambiguous with regard to separating
objects

- encoding of lists is non-intuitive in two senses --
   - for those who don't deal with functional languages, the idea of a
list in reverse order may not make a lot of sense
   - there is no explicit list terminator, unlike for structures.
   (both of these seem to not fare well in the "human readable" goal
stated in the spec.)

Now, I'm not saying that these are insurmountable problems, perhaps
they are just issues that I'd like to understand better.


>
> One thing I like about UBF(A) is that it should only take a few days
> to write a parser, while XML is estimated to take about 3 weeks.  Thus
> most developers should be able to bring a UBF(A) parser online in a
> very
> short time, perhaps about the same amount of effort required to just
> write a simple SAX or DOM parser (which uses an existing parser).  :)

Yes, I really love the idea and implementation of UBF(*). I wrote most
of a UBF(A) parser as a passenger driving to and from a mini-vacation
(I conveniently left my wallet at home and couldn't drive...) I just
rewrote the parser last night to try a different approach. Even the
harder stuff doesn't take _that_long to do.

Erik.


>
> --
> Shawn.
>
>   When smashing monuments, save the pedstals -- they always come in
> handy.
>   -- Stanislaw J. Lem, "Unkempt Thoughts"
>
Erik Pearson
Adaptations
desk +1 510 527 5437
cell +1 510 517 3122



Reply | Threaded
Open this post in threaded view
|

records generated from UBF

Erik Pearson-2
Well, `grimace`, some of the issues go away now that I realize that the
semantic tag uses backquote rather than single quote ...

[... tons snipped ...]

Erik



Reply | Threaded
Open this post in threaded view
|

records generated from UBF

Joe Williams-2
In reply to this post by Erik Pearson-2
On Sat, 19 Apr 2003, Erik Pearson wrote:

> 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)...)
>

IMHO this would be more difficult to parse :-)

  You should  think of UBF(A)  as a byte  code program designed  to be
executed by a push down autonoma.  As soon as you recognize *anything*
you just push it onto the stack.

So to parse:

        123 ~.....~

The parser proceeds as follows:


1) Recognize that "1" is the start of an integer
2) go get the integer
3) Blank terminates the integer so push the recognized integer
   "123" onto the stack
4) Recognize ~ - this means "here comes a memory buffer"
   the length will be on the top of the stack
   Pop the stack
5) collect 123 bytes into a memory buffer
6) push the memory buffer onto the stack
7) collect a ~

Step 7 is (or course) not necessary.

UFB(A) has a few "features" to make it not only easy to parse
but easy to read and write - Thus the trailing ~ is just there to make
it easier to read.

<aside>

In UBF(A)

        Opcode 123 means start a new struct
               125 means end of struct
               44  means element separator within a struct

So if you hit a byte 123 on input you start collecting a struct etc.

Coincidently 123, 125 and 44 are the ASCII byte codes for "{", "}" and ","

(but then again perhaps this was by design rather than accident :-)


</aside>

> 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.

Again this is just to make it easier to read - commas and white space
mean the same.

/Joe



> 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
>



Reply | Threaded
Open this post in threaded view
|

records generated from UBF

Joe Williams-2
In reply to this post by Erik Pearson-2

Good point :-) - I guess there should be one more operator meaning
undefined - The obvious choice would be "?"

This looks like something for UBF-2 (if there ever is a UBF-2 :-)

Otherwise you could use just # which is the nil terminator at the
end of a list - but you'd have to change the parser etc. (and the contract
checker to do this).

I haven't though about it a lot but at first sight using "?" might allow
a simplification of the contract rules using "?" instead of ANY - which
would make then more readable and possibly more powerful (a la Prolog)

/Joe



>
> I have a new concern too -- how to represent null (i.e. missing, blank)
> values?
> For strings it would be
> "" $
>
> for constants
> '' $
>
> for binary
> 0 ~~ $
>
> (or
> ~0~~ $
> if the tilde prefix is preferable),
>
> but for integers it would be
>
>   $
>
> .. that is, a blank. But this raises a few issues:
>
> 1. How do you carry the type information for a blank integer?
>
> 2. Is there a valid concept of typeless null? That is not only is the
> value blank, but it also carries not type information?
>
> 3. It seems impossible to represent a null tagged integer -- it would
> be indistinguishable from a plain constant.
>
> Do you or does anyone else have experience with confronting these
> issues?
>
> I can see that UBF(B) might help with some of these issues, since the
> usage of values within a particular context would imply their type.
> However, at this point I'm just concerned with getting plain old UBF(A).
>
> Also, one of the things I'm trying to keep an eye on is places where
> the spec introduces more work for the parser-builder. In my case, I
> would like to use this with multi-vendor data and message exchange. In
> these cases, having a clear, easy-to-implement spec is very important.
> People need to implement this stuff in all sots of weird languages and
> often in a hurry!
>
> Thanks,
>
> Erik.
>
>
>
> >
> > /Uffe
> >
> >
> Erik Pearson
> Adaptations
> desk +1 510 527 5437
> cell +1 510 517 3122
>



Reply | Threaded
Open this post in threaded view
|

records generated from UBF

Erik Pearson-2
In reply to this post by Joe Williams-2
Hi Joe,

Thanks for the clarification. I think the reason it was an issue for me
was the approach I had taken to write the parser, which was more akin
to:

- start reading a stream, byte at a time.
- feed bytes to whitespacecomsumer()
- on the first non-whitespce bytecode , you know what the upcoming
object is
- now feed bytes to a function which knows how to collect that object,
getint(), getstring(), etc.
- that function: collects the bytes, when it sees the object
termination condition, turns them into native object, returns that
object and the next function to use.

I've since rewritten the parser to rely on generalized stream-consuming
functions which respond to different types of byte collection and
detection requests (collect-until, collect-while, etc.). It is now
utilizes something of a little stack (actually an associative list to
store facts about each object as they are discovered - value, tag,
termination bytecode). It is implemented in Common Lisp, so it is a
little weird.

Anyway, not that you wanted to know all of _that_ ...

On Tuesday, April 22, 2003, at 01:25 AM, Joe Armstrong wrote:

> On Sat, 19 Apr 2003, Erik Pearson wrote:
>
>> 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)...)
>>
>
> IMHO this would be more difficult to parse :-)

I guess simplicity is in the eye of the beholder! Seriously, though, I
guess there are multiple issues to be juggled here...

- merit of the design (elegance, extensibility, etc.)
- efficiency (size of objects, ease of parsing)
- simplicity (amount of code to implement, number of words in the spec.)
- ease of implementation in various languages (since this is a "glue"
between disparate systems, this is important.)

Of course, what really grabbed me about UBF was that you (Joe) attacked
some of these issues head-on, without the usual XML b.s. (pardon me).

I think these issues become less relevant to the end user if they don't
have to implement their own clients and servers -- if there are free
clients (and possibly servers) for multiple platforms (java, tcl, c,
python, perl, vb, c#, com, scheme, lisp :) etc.) as hinted in the UBF
materials, then implementation issues are much lower in importance.
With free clients on your platform and language of choice, and a free
(and free) Erlang server, I guess no-one could complain about anything!



Erik.

>
>   You should  think of UBF(A)  as a byte  code program designed  to be
> executed by a push down autonoma.  As soon as you recognize *anything*
> you just push it onto the stack.
>
> So to parse:
>
> 123 ~.....~
>
> The parser proceeds as follows:
>
>
> 1) Recognize that "1" is the start of an integer
> 2) go get the integer
> 3) Blank terminates the integer so push the recognized integer
>    "123" onto the stack
> 4) Recognize ~ - this means "here comes a memory buffer"
>    the length will be on the top of the stack
>    Pop the stack
> 5) collect 123 bytes into a memory buffer
> 6) push the memory buffer onto the stack
> 7) collect a ~
>
> Step 7 is (or course) not necessary.
>
> UFB(A) has a few "features" to make it not only easy to parse
> but easy to read and write - Thus the trailing ~ is just there to make
> it easier to read.
>
> <aside>
>
> In UBF(A)
>
> Opcode 123 means start a new struct
>       125 means end of struct
>       44  means element separator within a struct
>
> So if you hit a byte 123 on input you start collecting a struct etc.
>
> Coincidently 123, 125 and 44 are the ASCII byte codes for "{", "}" and
> ","
>
> (but then again perhaps this was by design rather than accident :-)
>
>
> </aside>
>
>> 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.
>
> Again this is just to make it easier to read - commas and white space
> mean the same.

(But above didn't you say that comma is the bytecode for element
separation; if it is also the same as whitespace how can it separate.
Perhaps I need to enlarge the font on my monitor...)

I don't know if you saw my other notes, but the problem I was having is
the separation of objects within the structure. At that time I did not
realize that the bytecode for delimiting tags was the backquote -- I
thought it was single quote and thus the tag was just a constant. In
that case, one would have a problem keeping track of objects without an
explicit separator. With that confusion removed, that particular issue
goes away.

Another issue is that without an object separator (or the ? "null"
bytecode you suggested) you can't include missing/null objects because
it will just look like more whitespace (although you can include blank
strings, constants, etc. -- just not untagged integers)

Erik.


>
> /Joe
>
>
>
>> 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
>>
>
>
Erik Pearson
Adaptations
desk +1 510 527 5437
cell +1 510 517 3122