[ticker-dev] Merging chat and news messages?

[Phillips, Matthew]

I have to agree that "Subject" just feels wrong as the "Message" for chat
messages. I guess the general motivation here is that, since chat and news
are such similar things, It Would Be Bice If (tm) we could use exactly the
same base fields for both and that clients wouldn't have to care about the
difference if they didn't want to.

But if that can't be done cleanly (and it appears it can't), then I agree we
should accept that chat messages only have a Message field, news messages
have a Subject and Message field, and it's up to ticker clients to deal with
displaying a news messages' Subject in the tickertape and a chat messages'
Message.

My 2.2c (incl GST)

Cheers,

Matthew.

> -----Original Message-----
> From: Phil Cook [mailto:philc at itee.uq.edu.au]
> Sent: Friday, 19 July 2002 1:32 PM
> To: Ted Phelps; ticker-dev at dstc.edu.au
> Subject: Re: [ticker-dev] Merging chat and news messages?
> 
> 
> On Thursday 18 July 2002 08:09 pm, Ted Phelps wrote:
> > Klaus Alexander Seistrup may have said:
> > > I was under the impression that the 
> org.tickertape.message v2.0 was
> > > supposed to merge chat and news messages into a unified message
> > > format - a step that I welcome, since it somehow simplifies the
> > > writing of client implementations.
> >
> > I'm afraid that I'm not particularly keen on this idea.
> >
> > From my point of view, the format of a notification should not be
> > bent, folded or mutilated in order to accomodate a particular
> > consumer.  There's a tendency to make every notification into a
> > tickertape notification because that's the only UI we have, and this
> > feels like an extreme case of that tendency.  I'm not at all happy
> > with the idea of a chat message having a "Subject" field.
> 
> I tend to agree with Ted here.  Ted mentioned at the Ticker 
> workshop last year 
> that he wanted to develop a language for transforming 
> notifications in 
> xtickertape.  I think this is the better route to take, and 
> would also help 
> to avoid the "tendency to make every notification into a tickertape 
> notification".  If we've only got one UI, then we should make that UI 
> flexible enough to handle a wide range of notification formats.  
> 
> A notification transformation language would also complement 
> the subscription 
> language by further reducing the coupling between producers 
> and consumers.  
> Consumers that are flexible enough to subscribe to a wide range of 
> notifications (as many of the tickertape clients now are) 
> should be flexible 
> enough to do something useful with those notifications.  Any 
> consumer that 
> allows the user to specify an arbitrary subscription string, 
> arguably, is 
> incomplete if it doesn't let the user specify what to do with 
> notifications 
> that match that subscription.
> 
> So I propose we give some more thought to such a 
> transformation language, and 
> attempt to develop a library consumers can use to get at it.
> 
> Phil.
> ______________________________________________________________
> _______________
> Phil Cook						 "No 
> Neil, after you"
> Ph.D. student at large					
> 	- Buzz Aldrin
> School of Information Technology and Electrical Engineering
> The University of Queensland, QLD, 4072, Australia
>