Le 25/09/2011 11:54, Alexander Holler a écrit : > Am 25.09.2011 11:39, schrieb Kevin Smith: >> On Sun, Sep 25, 2011 at 10:34 AM, Alexander >> Holler<hol...@ahsoftware.de> wrote: >>> Am 24.09.2011 23:51, schrieb Waqas Hussain: >>>>> >>>>> And handling room-aliases on the server side would have many pitfalls >>>>> (e.g.the delay elements in the history). I'm not sure where else >>>>> room-JIDs >>>>> are used (besides in 'from'), that would require checking the >>>>> whole XEP >>>>> for >>>>> appearances of room-JIDs (which currently isn't that easy) ;) >>>>> >>>> >>>> Kev is correct. MUC aliasing can work fine without any protocol or >>>> client changes. A server doesn't need to forbid letting a client enter >>>> a room in two ways. It would work fine. And I can't think of any >>>> pitfalls regarding the delay element. >>> >>> The pitfall is that you can't stamp the delayed stanza when the >>> delaying >>> actually occurs, which means you have to do that somehow else. If >>> you do, >>> you will have to change that afterwards (when sending out). Stuff >>> like this >>> is what I call pitfalls. >> >> I don't see why aliasing would affect the way delay elements are >> inserted into room history. Please explain. > > The from in the delay element has to be the domain (alias) the > receiving occupant connected to. And the server doesn't know that when > the stanza will be stored. Anyway, implementing it somehow else is no > problem. > > But I don't want to continue this discussion. > I agree that it is possible without changing the XEP, so the original > request to change the XEP is fulfilled because it isn't needed. So > everyone can go on and implement it. > > Regards, > > Alexander > > A r...@conference.server.tld is changed to r...@muc.server.tld (conference.server.tld is now muc.server.tld in server config file), the question is: "How it is possible to create an alias if the old server muc (conference.server.tld) does not exist?"
Regards, -- BOCQUET Ludovic
smime.p7s
Description: Signature cryptographique S/MIME
