On Freitag, 16. März 2018 15:03:28 CET Tedd Sterr wrote: > I like the idea and design of 0394, and look forward to seeing these > extensions; the unholy hybrid attempting to shoehorn in 0393, not so much. > > Attempting to extend the inline text styling to support all of the > additional formatting features is going to result in plain text messages > that resemble Perl programs, which is really not good for readability. And > essentially forcing clients to support 0393,
A client can use 394 without support 393 just fine. I don’t see where you got
this notion from, I guess my initial mail on this was unclear.
> while also including
> additional styling that 0393 does not support will do nothing to aid
> compatibility.
The "unholy hybrid" is not about '393 compatibility in particular. It is about
gracefully falling back to plaintext in general. Making this compatible (to a
certain extent [1]) with '393 is just an added bonus.
> Regarding graceful degradation: there should be a service discovery string
> to indicate support for 0394; thus a sending client knows in advance
> whether to send 0394 formatting to another client.
This is the Feature Discovery fallacy (for the lack of a better term). Feature
Discovery does (currently) not really work. We have Carbons and MAM. You can’t
be sure whether the other side has clients which support or do not support a
feature and which are just currently not online. Not to mention MUCs and other
broadcast/multicast protocols. Is it reasonable to remove formatting options
just because one lurker in a MUC with 20 users does not have support? You also
generally won’t be able to see features of all clients in a Multi-Session Nick
situation. Relying on feature discovery is not going to solve anything.
> The sending client can still degrade gracefully - there are four
> possibilities: […]
See above.
kind regards,
Jonas
[1]: Full compatibility with '393 can’t be achieved anyways, because of
the intentional restrictions of '393. It would at most be an
approximation which---just like '393 itself and as designed---works
in *most* cases.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
