search

blambo / wave-protocol

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

ConversationThread.isInline is still used in some parts of the codebase #264

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago 

In Google Wave, there were four types of reply threads:

inline=false, no content anchor  => an indented reply thread outside the parent 
blip.
inline=false, with content anchor => corrupt data, but treated anyway as above
inline=true, no content anchor => unanchored inline reply, rendered at the end 
of the parent blip (inside).
inline=true, with content anchor => anchored inline reply, rendered at the 
content anchor (inside).

In Undercurrent / WIAB, this distinction based on the inline attribute in the 
manifest is no longer made.  Reply threads are just reply threads.  Any reply 
thread can have an anchor in its parent blip's content, and if there is such an 
anchor, the thread is rendered there, otherwise it is rendered at the end of 
the parent blip's content.  The rendering and behaviour of the two cases is 
identical (unlike Google Wave).  The only difference is the location where the 
thread is rendered.  Essentially, this means that "indented" replies, as 
opposed to "inline" replies, are gone.

All code that is causing divergent behaviour based on 
ConversationThread.isInline() needs to be fixed.  In most cases, the expression:
  ConversationThread.isInline()
can be replaced with:
  true
followed by consequent refactoring and dead-code removal etc.

Original issue reported on code.google.com by hearn...@google.com on 19 Apr 2011 at 10:17