[ticker-dev] new revision of ticker v3 spec

[David Arnold]

Approved: mdelvin
-->"Blaize" == Blaize Rhodes <blaize at dstc.edu.au> writes:

  Blaize> I think that the whole idea of a tickertape message format
  Blaize> is contra the elvin philosophy (which I see as allowing
  Blaize> increased scalability by decreasing coupling between
  Blaize> applications). 

ok.

  Blaize> Message formats are like channels in the effect that they
  Blaize> have on msg distribution (though perhaps at the higher level
  Blaize> of granularity of tuple collections and not at the
  Blaize> individual tuple level (where coupling occurs in channel
  Blaize> based services)). 

i half agree with this.  

i think it's necessary to define the minimum set of elements that a
Tickertape client application can reasonably expect to be present.

but there's nothing that prevents an application using that minimal
set of elements in conjunction with any others.

so i accept the argument that the combination of Group, From, Message,
Timeout and Message-Id forms a coupling between producers and
consumers.

but i think it's unfair to compare it to a pure channel-based system.

  Blaize> I reckon a better approach would be i) to ascribe semantics
  Blaize> to certain attributes (ontology-style) and then, ii) if you
  Blaize> like, apply your MUST and MAY conditions to the ontology to
  Blaize> define what's allowed in a standard "tickertape" msg.

personally, i'd be happy to adopt that approach.  i don't think it
would necessarily change the current specification a great deal.

i expect it will lead to different naming than we have now, and i
worry about the impact that would have on client implementations, but
perhaps if it can be resolved quickly?

  Blaize> The difference is that by defining attribute semantics
  Blaize> separately you allow reuse of those attributes in other msg
  Blaize> formats and decrease coupling between applications based on
  Blaize> the msg format adopted. 

in theory, yes.  but in practice, this aim is unlikely to be perfectly
achieved.

  Blaize> The advantage this *may* bring is that at some stage
  Blaize> previously unforseen applications can access the information
  Blaize> in the attributes without having to know about the msg
  Blaize> format(s) in which that attribute appears, i.e it decreases
  Blaize> coupling between applications.

i think you can approach this ideal position, but i don't believe that
it is reachable.

i have seen enterprise-wide attempts to define an ontology of variable
names, such that whenever you had to represent a particular entity,
you could look up the ontology and use the standard name.  this was a
fine idea, in theory, and in practice it partially worked.

but that was in a circumstance where it was actually possible to
define a single, global, enforced ontological standard.  i don't
believe that is completely practical with Elvin.


i'd suggest that the *combination* of names gives additional semantic
context, and that while attempting to maintain a common ontology is a
noble and worthwhile goal, applications will continue to rely on
combinations of attributes to determine relevance of messages.

this doesn't mean i'm not prepared to work on a common definition of
the semantics of attribute names, just that i think we need to be
realistic in anticipating its benefits.

  Blaize> Like I said, it has been said before, but I can't help
  Blaize> feeling it's anti-elvin doing it this way .

so, is anyone prepared to write up a definition of the semantic
concepts represented in a Tickertape message, and suggest names for
them?





d