[ticker-dev] My design objectives with Tickertape

[David Arnold]

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

  Ian> This is probably the most contentious goal i.e. one that
  Ian> others may not share.

i don't personally consider either the tickertape protocol or the
various bits of tickertape code to have demonstrating Elvin "best
practice" as a design goal.

of course, i would hope that tickertape (and tickertape programmers,
administrators, users, etc) would find good elvin practices useful and
beneficial.

imo, where they (spec and code) depart from Elvin best practice, it
should be because tickertape exists independently: it does not exist
primarily as an example elvin program.


i don't think this conflicts with your ranking of 2 and then 3, but i
think perhaps i consider 3 (being a good elvin demo) at a (much?)
lower priority?


  Ian> This includes examples of best practice in particular areas of
  Ian> Elvin application design e.g. attribute naming (this is the
  Ian> only justification I can see for changing attribute names in
  Ian> v3)

i attempted to change the naming in the 2.0 spec (which sticker alone
adopted), and again for 3.0, basically because i wanted to do it asap
and in particular before the hideous ugliness of ALL_CAPS became
entrenched forever.

imo (and i suppose that had a bit to do with it :-), it is not a
matter of demonstrating best naming practice, but rather allowing
tickertape programmers to have the benefits of a consistent and
aesthetically-tolerable specification with which to work.

but the motivation was not to demonstrate Elvin goodness, but to have
tickertape profit from the goodness.


  Ian> Tickertape may not be the ideal basis for this given its strong
  Ian> (but not necessarily total) channel orientation, but I think
  Ian> it's far and away the best example we have.

which is unfortunate.  
i think ticker deserves a life of its own.
ticker should do things the Tickertape Way (TM).

and naturally, that will overlap a lot with the Elvin Way, given that
many of the protagonists are the same, but i think there are times
when we tend to make the middleware drive the user experience, and i
hope to minimise them.

how does that gel with making attachments opaque at least partially so
that routers don't have to handle string ops on word documents?
that's probably another discussion.

in short though, it's not my only motivation.  while i'm concerned
with the implementation issues, i think i'm mostly interested in
distinguishing between attachments (which can be opaque) and the
message (which cannot).

if there is a user requirement for subscribe-able rich content, then i
wonder if we shouldn't be addressing that issue, rather than mucking
around with bolting it on the side as attachments?

but that's a tickertape-4.0 discussion ... 

  Ian> I see (2) and (3) as important (assuming nobody tells me to
  Ian> prioritise (1)), not so that (3) should ever be focussed on at
  Ian> the expense of (2), but neither so that (3) should be ignored
  Ian> just for the purposes of (2).

i think perhaps we diverge here: i would happily sacrifice 3 (being a
good example of an elvin program) if it impinged on 2 (being a good
tickertape (whatever that really is)).


  Ian> FYI, FWIW, YMMV, etc

interesting topic.

it might be interesting to articulate what makes ticker good (and
better than ICQ/AIM/Jabber/IRC/ytalk) as a statement of goals.  or it
might just be devisive and pointless.

Geraldine's (and Donaugh's) contribution was to make this sort of
observation from the sidelines, allowing us to adopt or not, as we
felt fit.  and she came from a Tickertape perspective, not Elvin.  

i think i miss that more than i knew.




d