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. /K
