Difference between revisions of "Talk:Protocol"
Jump to navigation
Jump to search
Rob Linden (talk | contribs) (Starting discussion about protocol stability.) |
Rob Linden (talk | contribs) |
||
Line 1: | Line 1: | ||
== Protocol Stability == | |||
We should have a discussion about protocol stability at some point. Which (if any) messages should be considered "set in stone", versus "could change from release to release"? What about protocol structure in general? There's a lot to talk about here, and much to be documented. As the system matures and as there's increased heterogeneity of clients, there's going to be more of a groundswell and need for stabilization. However, maintaining stringent backwards-compatibility is really hard work that takes away from time spent working on new features. -- [[User:Rob Linden|Rob Linden]] 14:56, 1 December 2006 (PST) | We should have a discussion about protocol stability at some point. Which (if any) messages should be considered "set in stone", versus "could change from release to release"? What about protocol structure in general? There's a lot to talk about here, and much to be documented. As the system matures and as there's increased heterogeneity of clients, there's going to be more of a groundswell and need for stabilization. However, maintaining stringent backwards-compatibility is really hard work that takes away from time spent working on new features. -- [[User:Rob Linden|Rob Linden]] 14:56, 1 December 2006 (PST) | ||
[[Category:Future Roundtables]] | [[Category:Future Roundtables]] |
Revision as of 14:59, 1 December 2006
Protocol Stability
We should have a discussion about protocol stability at some point. Which (if any) messages should be considered "set in stone", versus "could change from release to release"? What about protocol structure in general? There's a lot to talk about here, and much to be documented. As the system matures and as there's increased heterogeneity of clients, there's going to be more of a groundswell and need for stabilization. However, maintaining stringent backwards-compatibility is really hard work that takes away from time spent working on new features. -- Rob Linden 14:56, 1 December 2006 (PST)