[ticker-dev] new revision of ticker v3 spec

[David Arnold]

-->"Ian" == Ian Lister <ilister at dstc.edu.au> writes:

  >> ok, so let's find a better way.

  Ian> That would be good, but I am also OK to let Tickertape continue
  Ian> in the direction it is currently going, if that is what others
  Ian> want.

i'd really rather not hold up v3 much longer.  if a quick resolution
is possible, and there is a general acceptance of changes amongst the
client authors, then i'm happy to change.

otherwise, v4 is always possible.

  Ian> If the feeling is that the Tickertape way is divergent from the
  Ian> Elvin way rather than aligned with and the best example it can
  Ian> be of the Elvin way then Blaize's observation that giving
  Ian> standard meanings to attributes rather than whole notifications
  Ian> is more in the Elvin way is not relevant.

if there is benefit to Tickertape to be had, then i'd be surprised if
suggested changes were rejected outright.

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.

  Ian> So my point is relevant because it is tied to whether Blaize's
  Ian> point is relevant to Tickertape.

the fact that Tickertape is not Elvin doesn't mean that specifying
Tickertape notifications as a collection of independently-specified
Elvin attributes is not relevant.

  Ian> I think that this is unfortunate because I think Tickertape has
  Ian> a lot to give Elvin and other Elvin applications (and that
  Ian> Tickertape and other Elvin applications can potentially gain by
  Ian> sharing rather than being independent protocols designed only
  Ian> for their own purposes and not for future extension or use in
  Ian> ways that are not currently done).

what do you think Tickertape can give Elvin?

all design should attempt to anticipate future extension and
alternative uses.  i would argue that the draft v3 specification is
better than v2 or v1.x in that regard.  but improvements are always
welcome.

  Ian> I am also happy to do it, and I probably should do it given
  Ian> that I'm the one keen on it and you're the sceptic :-)

good.

  Ian> At the simplest level an example is the problem of units - an
  Ian> attribute `Timeout' is not useful without knowing whether a
  Ian> numeric value is in seconds, minutes, or years.

yep.

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

  Ian> The classic temperature sensor example is another case - what
  Ian> units is `Temperature' in? Is it reasonable to define that
  Ian> applications should always use metric units of a particular
  Ian> scale?

both of these cases reflect similar issues in API design.  pick the
units that are most broadly applicable, and accept that sooner or
later, someone will need to more precision or greater range than
you've anticipated.

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.


"Temperature" is easier for me -- it has a simpler, more generic
semantics.  it should always be a floating point value in degrees
kelvin.


  Ian> The renaming of Attachment to MIME-Attachment is really another
  Ian> example of the same problem - by specifying the encoding of the
  Ian> attribute's value in the attribute's name we make it clear what
  Ian> to expect in the attachment, but if there were other common
  Ian> ways of representing attachments then any applications that
  Ian> chose those methods would lose any potential for interoperating
  Ian> with Tickertape's attachments.

cue correlation?

  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.

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.

  Ian> There are other encoding issues with simpler solutions, such as
  Ian> defining that lists of values should be `|' separated strings
  Ian> (as the presence protocol has defined for a few attributes it
  Ian> uses), but richer ability to represent more structured data in
  Ian> Elvin natively would help.

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.

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

  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?  

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.

  Ian> Any thoughts on any of this?

of course!

  Ian> Is this all just evidence that it won't work?

not necessarily, just grounds for healthy scepticism :-)




d