On Wed, Mar 2, 2011 at 1:22 PM, Gregg Vanderheiden <[email protected]> wrote: > For these and similar reasons - it is important that such capabilities be > supported. Users can turn them on or not but they need to be able to.
On this note, I refer back to my previous comment about this spec being quite lengthy and relatively involved. As an XMPP client developer, I can't see this spec getting a great deal of traction outside specialised clients if an implementation requires complexity (Mark's claim was that a prototype of this feature took him two days. So double that to get a non-prototype version, and double it again if you're allowing for the developers not being immersed in this field, round down a bit because you're generous, and you're still looking at 6 or 7 days of effort to implement the feature - the number of other features I could put in Swift in that time, or would have been able to put in Psi in that time, is significant). If the spec is pain-free to implement at the baseline, it's much more likely to gain implementation in typical clients. If the aim is to get the maximum deployed base of compatible clients, I suggest that the best approach is to have a very simple baseline. My original suggestion of retransmitting <fragment/> equivalents every (second) so often is a simple baseline that's easy to implement in a client in hours rather than days. I see that what is specified here is more feature-rich than <fragment>s, and the arguments seem compelling for it giving a better user experience for a subset of users (I doubt I'm observant enough, but I'm willing to accept that others are). It seems appropriate for these features to be available for implementation as well (and to be backwards compatible with the simple version). If the user experience difference is significant, I expect that any client author who would implement the full spec when it's all mandatory would also implement it when it's part optional. I also expect that you'd get additional implementation in clients where the authors would not implement it if it's all mandatory. My predictions may be wrong (it's too light outside for me to have even checked the positions of the stars today), but if the options are a) a small group of clients that implement everything; or b) the same group of clients that implement everything, together with other clients that implement a baseline that can interoperate with them; then I think that (b) is the choice that serves people interested in this feature best. I think mandating things that people don't want to implement means they'll implement nothing, not that they'll implement everything. /K
