Peter Saint-Andre píše v So 30. 01. 2010 v 06:45 -0700: > Thanks, guys. I will complete my review of Section 7 this weekend. It > was a busy week... > > On 1/29/10 5:57 PM, Jiří Zárevúcky wrote: > > So here is my list of notes: > > > > 1) > > Are we going to finally replace those creepy status codes? > > Yes, I will work on that soon. >
Great! > > 2) > > Just bellow example 22, there is this text: > > > > "If the user is entering a room that is non-anonymous (i.e., which > > informs all occupants of each occupant's full JID as shown above), the > > service SHOULD allow the user to enter the room ..." > > > > What is the alternative here? > > Deny entry based on some undefined security policy, I think. > Right. > > 3) > > In the same place, the inclusion of status code for non-anonymous room > > is just recommended, and the service can instead choose to send a > > message with the status code. > > > > While that second possibility is perhaps more suited for very restricted > > clients, it's just "MAY" and thus not wise to rely on. In effect, the > > client still needs to expect both possibilities, filter the server-sent > > message if necessary and provide it's own to be consistent. > > > > Thus, I'd really like to see the presence-based notification promoted to > > MUST and the message dropped entirely. The same goes of every other > > place where this choice is provided (e.g. logging notification). > > I *think* that's probably a good idea but I'm not 100% sure yet. Do you > mean that we'd never use the message notifications and always use > presence instead? I don't see a good reason to generate presence if > there's no underlying presence change (other than a room config change). > You're right, I've forgotten that the settings can change mid-conversation. I only meant notification while entering the room. However, wouldn't it be better to simply come up with a general mechanism that notifies everyone about any (public) change in configuration? > > 4) > > Section 7.1.14 > > "If the user is entering a room in which the discussions are logged to a > > public archive (often accessible via HTTP), the service SHOULD allow the > > user to enter the room" > > > > The same question as with point 1. What's the alternative? > > See above. > > > 5) > > "The service SHOULD send all discussion history messages before > > delivering any "live" messages sent after the user enters the room." > > > > IMO, this should be a MUST. > > Agreed. > > > 6) > > Then, there is also the problem with the client not knowing whether it > > has all the history until a live message comes. > > Yes, that is a long-standing problem. I think it's fixed if we say that > history MUST be sent before live messages, because history messages MUST > have a delay tag from the service. Correct? > That works as long as the room is active. There may be no live messages at all. > > 7) > > Spec is not specific about how the current discussion topic is to be > > communicated when occupant enters a room. My vote is for subject changes > > being part of the history, since they are important context for the > > messages. If no change was made as far as history goes, it would be the > > first message in history. > > Yes, that is currently unspecified or underspecified, and I know that > (for instance) Openfire and ejabberd interpret the spec differently. > > I don't think that the subject message is really part of the history, in > the sense that the subject could have been set before the last X > messages were generated (where "X" is the size of the history). However, > the subject might also have been changed in the middle of those X > messages. :) So I see a few options: > > 1. Send history, send subject, send live messages. > 2. Send subject, send history, send live messages. > 3. Send subject at time when history started, send history including any > subject changes, send live messages. > > #3 requires the MUC service to keep more state. I don't think so. It would just treat subject changes as regular part of history, except it would always keep the one that pre-dates any other history. > In general I see the > subject as the *current* room topic and I don't think it is the > responsibility of the service to maintain historical information about > the prior subjects, so I think #1 is best (plus it provides a nice > demarcation between historical messages and live messages, if there is a > subject). > That's where I disagree, purely from the user's perspective. I'd like to see prior subject changes. Other than that, #1 is good as well, since it solves the history problem, though I'd prefer #3. > > That's all for now. Perhaps I'll remember something else later. :) > > Thanks! > My pleasure. :) > Peter >
signature.asc
Description: Toto je digitálně podepsaná část zprávy
