[ticker-dev] Latest draft

[Phillips, Matthew]

[David]
> Do sticker, aquatik or eTiks support 
> Replaces/Replacement/REPLACEMENT ?

I haven't implemented this in Sticker, partly due to the fact that I don't have anything that would use it and partly due to the possible hackability opened up by the feature. One solution to the latter might be to mark messages intended to be replaced with an attribute.

>   Ian> At the risk of pushing my luck with the Timeout attribute I'd
>   Ian> like to see a recommendation in the draft that producers not
>   Ian> specify arbitrary message timeouts i.e. that unless there is a
>   Ian> specific reason that the producer doesn't believe a message
>   Ian> will have validity after a certain time then a Timeout should
>   Ian> not be specified. This means that interactive clients would
>   Ian> default to having an unspecified timeout for each message.
> 
> The field is optional, so my reading would make this interpretation
> natural from the spec text itself .. if you have no need to indicate a
> useful lifetime of a message, then don't use a Timeout.
> 
> Obviously existing clients tend to always include it, if only for
> reasons of unthinking compatibility with the original Elvin3 Python
> Tickertape GUI :-)
> 
> I'm not sure this should be pushed via the spec?  But maybe?

A note about only including it when it has meaning might be good.

>   Ian> The Distribution attribute is the only other one covered by the
>   Ian> draft that I am uncertain about. Sticker uses CLASSIFIED and
>   Ian> UNCLASSIFIED (and now `world'?) and DSTO filters traffic based
>   Ian> on it, but I'm not aware of any other client implementation or
>   Ian> organisation using it.
> 
> Yet .. I'm fairly tempted to start Mantara using this, for example on
> "Chat" ...

My current usage is "Distribution: world" for allowing a message outside, which should make sense at most sites. The older UNCLASSIFIED: 1 and Classification: UNCLASSIFIED will be retired when the v1 format is.

>   Ian> I'm not particularly familiar with Sticker but IIRC it has a
>   Ian> toggle control to choose between the two values, which are
>   Ian> hard-coded into the application rather than configurable by the
>   Ian> organisation (perhaps this has changed since I last looked
>   Ian> though).
> 
> I think the values used to be set in a properties file?  But I think
> you're right in that it uses a toggle button .. Matthew?

It does use a toggle (to be a checkbox in 3.1) to set this. The value that gets attached will be settable in 3.1 also (currently it's hardwired).

> We wanted two basic things:
> 
> a) A reply to a message should default to the same Distribution as the
>    original message

Sounds reasonable. However I'd agree with Ian's comment about confusing lists of scopes (snipped). The key problem we're trying to solve is the selective restriction of messages to a local site. Support for lists of (possibly nested) distribution scopes seem like a good idea to us computer scientists, but not many people (Bill excluded ;) would actually use this, so I'd think the cognitive overhead of adding all this to the UI wouldn't pay off. By boiling it down to a boolean "world" flag for messages, Sticker keeps it simple and fairly obvious - this apprpach has proven itself over extended use. However, I'd be open to the idea of allowing multple scopes (eg local, participant and world) choosable by a combo box if explicitly set in the site config.

So I'd suggest at least two defined values for Distribition: "local" and "world".

> My suggestion would be to move to it from its current position as
> "Optional" into a new section, "Experimental".

I'd like to leave it as an optional field.

> I'm one of those people who is happy that "Chat" and "chat" are
> different things.  I know there exist many people who think they're
> sufficiently similar that they should be considered the same thing in
> contexts like this.

> Anyone want to oppose the forces of history on this?

Yes, please :) I'm one of those people that like the "case-preserving but not case-sensitive" approach for names that people refer to things by. Unlike in programming languages, I can't see a good reason to consider CHAT and Chat to be different groups. I realise case-insensitivity is complex outside of the Roman alphabet, but I'm willing to deal with that if a bunch of irate Arabic speakers complain ;)

Cheers,

Matthew.