UBF byte register question

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

UBF byte register question

Erik Pearson-2
I'm wondering what the scope and lifetime of a UBF byte register is
supposed to be. The byte register allows the association of an
arbitrary UBF value with a single byte (that byte being any byte that
is not reserved by UBF.)

<background (or my attempt at such)>

The reason for the byte register is to allow more compact UBF messages,
since you can first send several commonly used values which are
associated with a specific byte. When that byte is seen later, the
associated value replaces the byte.

The register is set by sending

value >B

where value is any UBF value, > means "store in", and B is any byte
that is not reserved by UBF(A).

E.g.

   "Universal Binary Format" >U
   U $

would be equivalent to

   "Universal Binary Format" $

or

   'person' >p
   "Brown" >b
   # {p "John" b} &
     {p "Patricia" b} &
     {p "James" b} & $

would be equivalent to

   # {'person' "John" "Brown"}  &
     {'person' "Patricia" "Brown"} &
     {'person' "James" "Brown"} & $

</background>

So I'm wondering long the byte register should live for, and who should
see it.

The spec (http://www.sics.se/~joe/ubf/site/ubfa.html) doesn't specify,
as far as I can tell.

My best guess is that the the byte registers are only valid for the
single object following one or more byte register settings. The only
unit of transaction at UBF(A) is the data object, which is terminated
with a $ (dollar sign.). However, this would make the byte register
useful only for longish lists which contain repeated elements.

I am tempted to suggest that the byte register could live for a longer
span -- for the length of some sort of 'session' (network connection,
etc.) However, such concepts don't live in the realm of UBF(A).

It would also be tempting to think of the byte register having a longer
lifetime, allowing for a dynamic cache of frequently used values to
persist between a client and server (adjusted by analyzing the
frequency and size of objects being transmitted).

As to who should see a given byte register, if the span of the byte
register is a single object (or session), then it would clearly be
valid only for the current client. Since there is no concept of client
at UBF(A), there is really no sense in making this distinction.
However, if a byte register could persist for a longer period of time,
it would make sense to address the issue of multiple sessions or
clients accessing the same byte register.

Anyway, thanks for bearing with my seemingly endless UBF blitherings!


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



Reply | Threaded
Open this post in threaded view
|

UBF byte register question

Joe Williams-2
On Thu, 24 Apr 2003, Erik Pearson wrote:

> I'm wondering what the scope and lifetime of a UBF byte register is
> supposed to be. The byte register allows the association of an
> arbitrary UBF value with a single byte (that byte being any byte that
> is not reserved by UBF.)
>
 
... good question ... :-)

> background (or my attempt at such)>
>
> The reason for the byte register is to allow more compact UBF messages,
> since you can first send several commonly used values which are
> associated with a specific byte. When that byte is seen later, the
> associated value replaces the byte.
>
> The register is set by sending
>
> value >B
>
> where value is any UBF value, > means "store in", and B is any byte
> that is not reserved by UBF(A).
>
> E.g.
>
>    "Universal Binary Format" >U
>    U $
>
> would be equivalent to
>
>    "Universal Binary Format" $
>
> or
>
>    'person' >p
>    "Brown" >b
>    # {p "John" b} &
>      {p "Patricia" b} &
>      {p "James" b} & $
>
> would be equivalent to
>
>    # {'person' "John" "Brown"}  &
>      {'person' "Patricia" "Brown"} &
>      {'person' "James" "Brown"} & $
>
> </background>
>
> So I'm wondering long the byte register should live for, and who should
> see it.

There is actually an optimal (though unimplementable) algorithm -
it's comes from the old "page replacement algorithm"

It is "When you run out of byte registers, you have to throw one away -
(ie reuse it) - so all you do is reuse the next register whose next future
reference is longest away in time from the current usage."

  To implement this needs the pre-cognitive will_receive(Msg) statement
(Bj?rn)

will_receive(X) means that the message X will be received at some
point in time in the future, and returns the value of this time.

In pseudo code

        Ts = map(fun(I) -> {will_receive(I), I} end, ByteRegisters),
        B = element(2,hd(reverse(sort(Ts))),
               
This should work (if I understand things correctly) on a quantum computer -
otherwise don't hold your breath ...


>
> The spec (http://www.sics.se/~joe/ubf/site/ubfa.html) doesn't specify,
> as far as I can tell.
>

Correct - this was *deliberate* :-)

Golly - so we actually need yet ANOTHER operator (say !) which means
"clear the byte cache" - or even

Two operators say 'atom' ^ and 'atom' = which could save and restore
a bye cache "context"

If you encounter ^ you should *save* all the byte cache entries in a
object named "context" - otherwise you restore the context - this
could make for some *very* efficient protocols.



> My best guess is that the the byte registers are only valid for the
> single object following one or more byte register settings. The only
> unit of transaction at UBF(A) is the data object, which is terminated
> with a $ (dollar sign.). However, this would make the byte register
> useful only for longish lists which contain repeated elements.
>
> I am tempted to suggest that the byte register could live for a longer
> span -- for the length of some sort of 'session' (network connection,
> etc.) However, such concepts don't live in the realm of UBF(A).
>
> It would also be tempting to think of the byte register having a longer
> lifetime, allowing for a dynamic cache of frequently used values to
> persist between a client and server (adjusted by analyzing the
> frequency and size of objects being transmitted).
>
> As to who should see a given byte register, if the span of the byte
> register is a single object (or session), then it would clearly be
> valid only for the current client. Since there is no concept of client
> at UBF(A), there is really no sense in making this distinction.
> However, if a byte register could persist for a longer period of time,
> it would make sense to address the issue of multiple sessions or
> clients accessing the same byte register.
>
> Anyway, thanks for bearing with my seemingly endless UBF blitherings!
>

Carry on please

/Joe

PS the above posting contained at least one joke.
 
>
> Erik Pearson
> Adaptations
> desk +1 510 527 5437
> cell +1 510 517 3122
>