[ticker-dev] new revision of ticker v3 spec

[Ian Lister]

On Thu, 10 Oct 2002, David Arnold wrote:
>i don't see that it's possible to build a community of compatible
>applications without specifying a collection of attributes with common
>purpose.  so while the approach to naming and definition of attributes
>might be different, i'm not sure that the resulting specification
>would change dramatically.

I agree, but I see the difference being that we would design Tickertape to
be a part of a potential community of compatible applications. Recently it
has seemed that it is being developed more as a standalone application
without consideration for interoperating with other applications, but
that's possibly an inaccurate perception on my part.

>what do you think Tickertape can give Elvin?

The ability to support a variety of other applications interoperating with
and getting value from existing Tickertape users, applications and traffic
without Tickertape having to be explicitly designed to support these other
applications and without these other applications having to be contorted
to deal with `the Tickertape way'.

Generally and perhaps more importantly, point (3) in my original mail is
about Tickertape giving Elvin a good example of how to design an
application for Elvin.

>  Ian> Naming attributes `Timeout-Minutes' is not so useful because it
>  Ian> segregates information based on (easily convertible) units
>  Ian> (and/or requires applications to represent the same information
>  Ian> in many different ways).
>
>can you suggest an alternative?

I would go with `Timeout' being defined as being in some arbitrary unit
(as below).

>i think it is perfectly acceptable to include the unit of measurement
>(if appropriate) in the semantics of an attribute.  i'm less
>enthusiastic about including the units in the name -- you cannot put
>full semantic information into the name, so you might as well put the
>units into the same "offline" description as the remainder of the
>context?

Yep, I agree, at least in cases where units are easily convertible in both
directions without loss. In the more general encoding case this may not
always be true.

>calling the anticipated relevant lifetime of a text message "Timeout"
>is probably the first problem to be addressed.
>
>given the general acceptance of minutes as the appropriate unit at the
>ticker-2k workshop, it would seem that the intended semantics have a
>natural range (as minutes).  on the other hand, "Timeout" implies
>quite broad semantics to me, and my immediate inclination would be to
>use milliseconds as the unit.
>
>to me, this indicates strongly that there is a mismatch between the
>name and the semantics in the Tickertape context.

Yep. So, anybody up for defining `Timeout' to be in milliseconds? Or
perhaps for compromise we could put it in seconds and allow applications
wanting finer control to use floats?

>  Ian> In this case it seems that declaring that attachments should be
>  Ian> in MIME whenever possible makes sense, but then perhaps the
>  Ian> `Attachment' attribute should be defined to be MIME and the
>  Ian> `MIME-' prefix in the attribute name (which is really only
>  Ian> there to specify encoding) should be dropped.
>
>that was my initial logic.

So...back to `Attachment' then? ;-)  Seems reasonable given the way we're
currently heading.

>but given the general enthusiasm for using structured notifications to
>hold attachments, i think anticipating that alternative makes some
>sense, and thus distinguishing now is helpful.

Hmm...perhaps...

>more complex, structured respresentations of data might also increase
>the chance that different applications represent the same information
>in incompatible ways.
>
>not that a natively structured representation is less transparent than
>an encoding convention for a simpler data type, but more that if it is
>possible to represent complex data in a single message, programmers
>will no longer be "encouraged" to find simpler representations.

That is true - hence even greater need for predefined attribute structures
;-)

>anyway, this is probably getting a little off-topic.

Perhaps for this list, but I think it would (or should) be on-topic for
elvin-dev. Perhaps we should move there? (If it's not on topic for
elvin-dev or elvin-users then we need somewhere it is on-topic, because it
is important :-)

>  Ian> Without it we rely on ad-hoc methods (such as the `|' list
>  Ian> representation) and/or stuffing external structured formats
>  Ian> such as MIME and XML into notifications, losing ability to
>  Ian> (effectively) subscribe to their content.
>
>where does this line of argument end?

At some appropriate trade-off ;-)

>consider: messages should be objects, because any subscription
>language that operates on decapsulated data is incapable of profiting
>from the embedded semantics provided by class methods.
>
>structured data is a step towards active networks -- not that i reject
>it necessarily on that basis, but i don't find the argument that
>structured data is necessary for effective subscriptions particularly
>compelling because taking it further (effectively to active
>networking) is clearly (imo) not elvin.

I have always seen CBR as a big step towards active networks, and allowing
CBR on more structured data doesn't seem like (relatively) much of a
further step (just doing the same thing better).

On Fri, 11 Oct 2002, David Arnold wrote:
>so, thinking last night, i started by trying to name the elements of a
>tickertape notification as standalone entities.
>
>this is reasonably involved, so let me start with just one:
>
>From

[snip]

In the area of user identifiers we currently have two distinct types:

1. A `screen name', used in Tickertape, the presence protocol and
   coffeebiff. I would describe this as something like `an informal short
   name (possibly a login name), which may optionally have appended an `@'
   symbol followed by a short informal organisational or physical
   location qualifier' (where `short' may be defined more exactly in terms
   of words, characters, and/or just by example).

2. A `unique name', used in the presence protocol, which is modeled after
   an email address and would have a description similar to the above but
   mandating a unique domain part (and a unique name within the domain).

The fact that the presence protocol already distinguishes the two (and
that the other protocols' usages fit neatly and fairly consistently into
type 1) seems to lend weight to this classification.

>i'm kinda interested in this particular attribute, because i think it
>is a good example of the issues involved in attempting to specify
>naming and semantics independent of their application.

Yep.

Ian