hitrust / google-wave-resources

Automatically exported from code.google.com/p/google-wave-resources
1 stars 0 forks source link

Allow state updates that DO not bubble up as being 'unread' #555

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
As more diverse gadgets are being created, data is being stored in the 
gadget's state that is vital to the application, but does not need alert 
other users of the change.

This functionality would be handy in places where content viewable by the 
gadget does not change meaning, but data still needs to be stored.

For example, the Paginator gadget requires state updates to store current 
participants locations, however this adds nothing content-wise to the wave. 
Therefore, an option to update the state but prevent marking the blip as 
'unread' is very welcome.

I can see this kind of behaviour being applicable to robots aswell, such as 
text-correctors and converters. CleanTXT corrects textual errors, but does 
a blip really require attention from a user if all CleanTXT has done is 
correct a spelling error? No, as the content itself hasn't changed.

Just to be clear, 'unread' behaviour would be optional, and chosen by the 
extension, defaulting to the current behaviour.

Thoughts? 

Original issue reported on code.google.com by wonderso...@gmail.com on 5 Dec 2009 at 2:43

GoogleCodeExporter commented 9 years ago
We have several ideas on the team about ways of having "less important" state 
in 
gadgets. One idea, already filed in the tracker, is for gadgets to mark the 
importance 
of each state (issue 136). Another idea is to have different types of state, a 
"edit" 
state and a "position/presence" state. The "position/presence" state changes 
would 
only matter to the users that are currently in the Wave, while the "edit" state 
changes would matter to anyone on the Wave (marking as unread). Would that 
proposal 
meet your needs?

Original comment by pamela.fox on 10 Dec 2009 at 12:15

GoogleCodeExporter commented 9 years ago
Yeah, that's exactly what I had in mind. The 'edit' changes would be changes 
that are 
changing the content and would show as unread blips in the client, and the 
'presentation' (a bit more concise than position/presence, or maybe it should 
be 
'data') would not. Instead, the data is just saved and that is it. 

I know it was mainly for gadgets, such as 'realtimey' ones, but I do think 
robots 
could benefit aswell. For example, Acronym Decoder (my main robot) expands 
acronyms 
in realtime. Does it really need to set the blip as 'unread' just because of 
that 
tiny change that assists in the document, but it doesn't actually add any new 
content.

Original comment by wonderso...@gmail.com on 10 Dec 2009 at 6:45