My design objectives with Tickertape

[Ian Lister]

In some of the recent discussions about Tickertape v3 (specifically
most recently the structure of attachments) it seems that various people
have been looking at it from differing viewpoints, with apparently
slightly different design goals. I thought it might be useful if I
explained where I'm coming from.

I see three major potential areas of Tickertape's value:

1. As a commercial product

  This isn't the best forum for talking about commercial issues, but
  I don't think commercialisation of Tickertape is a current major goal.

2. As a useful collaboration tool

  Obviously we all use Tickertape for day-to-day communication so things
  that are of practical use are important. This is also very compatible
  with (1) above.

3. As an example Elvin application

  This is probably the most contentious goal i.e. one that others may not
  share. This includes examples of best practice in particular areas of
  Elvin application design e.g. attribute naming (this is the only
  justification I can see for changing attribute names in v3) and design
  to best show off Elvin's unique features such as the security mechanism,
  content based routing, decoupling of components, and flexible design to
  allow compatible future use in ways not thought of when the application
  was first designed. Tickertape may not be the ideal basis for this given
  its strong (but not necessarily total) channel orientation, but I think
  it's far and away the best example we have.

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

FYI, FWIW, YMMV, etc

Ian