Am 25.09.2011 11:39, schrieb Kevin Smith:
On Sun, Sep 25, 2011 at 10:34 AM, Alexander Holler<[email protected]> 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
