On Wed, Jul 11, 2018 at 07:52:55AM +0200, Jonas Wielicki wrote:
> Is there a reason to not use a presence type="error"? I’d expect clients to
> handle those already.
Mostly becasue I simply copied code from the room destruction handler.
> I’d use a type error, which encodes the semantics
On 11 Jul 2018, at 03:02, Kim Alvefur wrote:
>
> Hello list,
>
> I have implemented tombstones for destroyed MUC rooms. My reading of the
> sacred texts did not give me enlightenment as how to inform someone
> who's attempting to enter the remains of such a place. I've so far opted
> to return
On 11.07.2018 07:52, Jonas Wielicki wrote:
> On Mittwoch, 11. Juli 2018 04:02:23 CEST Kim Alvefur wrote:
>> Hello list,
>>
>> I have implemented tombstones for destroyed MUC rooms. My reading of the
>> sacred texts did not give me enlightenment as how to inform someone
>> who's attempting to enter
Either include status code 110 in the unavailable presence or use an
error presence.
The XEP is a bit fuzzy on when to use what. But I won’t be able to
parse an unavailable w/o 110
So in your case (a join attempt to the tombstone) I have a slight
personal preference toward error; But I’m ok with
On Mittwoch, 11. Juli 2018 04:02:23 CEST Kim Alvefur wrote:
> Hello list,
>
> I have implemented tombstones for destroyed MUC rooms. My reading of the
> sacred texts did not give me enlightenment as how to inform someone
> who's attempting to enter the remains of such a place. I've so far opted
>
Hello list,
I have implemented tombstones for destroyed MUC rooms. My reading of the
sacred texts did not give me enlightenment as how to inform someone
who's attempting to enter the remains of such a place. I've so far opted
to return an with the same child
that was in the inital announcement
