[ticker-dev] My design objectives with Tickertape

[Phillips, Matthew]

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

This is a bit off-topic, but it's something that I've been pondering quite a bit lately: why do I feel that tickertape is better than/different to current instant messaging products? Right now there's a possibility that Elvin could be inserted into the Defence toolkit soley as a tickertape router, but why shouldn't I be recommending AIM or Lotus SameTime instead? Especially given that Defence already has a big investment in Lotus Notes, so SameTime would be a logical choice.

So here's how tickertape beats IM from my point of view:

(a) No sessions: it's "always on". You don't join a group, have a conversation in a window and then leave. You don't even need to join groups or know what groups might out there, you may be just picking message threads based on a filter expression (which is why I think Thread-Id is important). This makes tickertape as useful for broadcast alerts, news and enterprise instrumentation as it is for conversations between people.

(b) Extensible: you can write a four line Python script to publish ticker messages. The other systems have big API's that worry about servers and logins and sessions and the many things that could go wrong establishing them. There's a lot of talk in Defence right now about "high tempo" operations ie reacting and adapting faster than the opponent. If you can safely and quickly add new info services in the field without installing infrastructure (mpossible in an operational environment) you can better adapt to unforseen needs and hence, hopefully, react faster.

(c) Robust: not only can you easily setup failover servers, but you can rely on them working sensibly because there is no state on the server for tickertape or presence.

Any other ammunition gratefully accepted ;)

Cheers,

Matthew.