Michal 'vorner' Vaner wrote: > On Thu, Jul 19, 2007 at 03:55:53PM -0600, Peter Saint-Andre wrote: >> Understand that the main driver here is Google Talk. You can't receive >> messages in Google Talk unless you add the sender of the incoming >> message to your roster first. That doesn't work with random chat rooms, >> with the result that Google Talk users can't join chatrooms on the >> Jabber network. That's a shame. Direct invitations would enable us to >> work around that. > > I got that. I just don't like workarounds from the principle. But it is > just my opinion.
I agree -- in principle. :) > So just one last question - how does a client know, when to send direct > or usual presence? I don't know. :/ > Sends both? Perhaps. Inviting people to rooms happens infrequently enough that it's not a bandwidth issue. But it may be confusing for the receiving client to get two invitations. Then do we need some logic for checking duplicate invitations? Ick. > Or user chooses? Probably not a good idea to force the user to choose. > Or some heuristics? > (@gmail.com -> direct, otherwise usual?) Well @gmail is only one example. Other services may do that, too. I understand why Google Talk has this policy, so I'm not going to argue them out of it. But it does introduce complications. Maybe your suggestion is best -- ask the MUC room what you should include in the invitation and it tells you. If you include the invitee's JID, the service could add the invitee to the member list at the same time. But that's not the road we went down in 2002 or whatever, so changing it now introduces potential incompatibilities. /me ponders Peter
smime.p7s
Description: S/MIME Cryptographic Signature
