Re: [Standards] [STANDARDS] XEP-0394: too weak to replace XEP-0071

> This is true, however mostly these are quite coarse-grained. Extensions with > lots of optional > parts inside - I'm thinking about XEP-0060 for example - tend to end up with > various interop issues. I don't disagree with that, and I'm not suggesting 0394 turns into a mass of optional

Re: [Standards] [STANDARDS] XEP-0394: too weak to replace XEP-0071

On 16 Mar 2018 17:49, "Tedd Sterr" wrote: > If you ever intend to make XMPP adopted by masses, zillion of optional > features is actually a bad solution. XMPP is nothing but optional features! Beyond XMPP-CORE and XMPP-IM, everything else is optional. See

Re: [Standards] [STANDARDS] XEP-0394: too weak to replace XEP-0071

> If you ever intend to make XMPP adopted by masses, zillion of optional > features is actually a bad solution. XMPP is nothing but optional features! Beyond XMPP-CORE and XMPP-IM, everything else is optional. See https://xmpp.org/extensions/ for just how many optional features there are.

Re: [Standards] [STANDARDS] XEP-0394: too weak to replace XEP-0071

> Some users want it, some don't. Including it as an optional feature is a > good solution. If you ever intend to make XMPP adopted by masses, zillion of optional features is actually a bad solution. -- Ненахов Андрей Директор ООО "Редсолюшн" (Челябинск) (351) 750-50-04

Re: [Standards] [STANDARDS] XEP-0394: too weak to replace XEP-0071

> XMPP can offer so many possibilities to it's users. Everyone can have > a very special capability that only he and his chat partner will use. > The downside is that total userbase would be 700 users. > With so many unsolved problems concentrating on features that worsen > UX and make client

Re: [Standards] [STANDARDS] XEP-0394: too weak to replace XEP-0071

I really don't see the problem - clients would surely implement such things? They could, but they're not required to. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org

Re: [Standards] [STANDARDS] XEP-0394: too weak to replace XEP-0071

> You're not forced to display colours in your client, but why force others not > to be able? XMPP can offer so many possibilities to it's users. Everyone can have a very special capability that only he and his chat partner will use. The downside is that total userbase would be 700 users. With

Re: [Standards] [STANDARDS] XEP-0394: too weak to replace XEP-0071

> Sender can't know what color scheme recipient has. It can be light or > dark mode, where colors are inverted. There is no way to make text > look consistently good if it's using various colors, and attempt to > display user-colored text would lead to chat window looking like > Geocities-era

Re: [Standards] [STANDARDS] XEP-0394: too weak to replace XEP-0071

> It could be, but given that this was a feature before and no client ever > implemented this > I don't see why it's something we should suddenly rely on now. It doesn't have to be relied upon - I suggested a simple solution to the problem of lacking contrast between text and background

Re: [Standards] [STANDARDS] XEP-0394: too weak to replace XEP-0071

> I agree with not supporting explicit font faces and sizes, also background > colouring, but text colour can be used to convey useful information. Of > course this could be abused, but so could many other features. Sender can't know what color scheme recipient has. It can be light or dark mode,

Re: [Standards] [STANDARDS] XEP-0394: too weak to replace XEP-0071

On 16 March 2018 at 15:58, Sam Whited wrote: > On Fri, Mar 16, 2018, at 09:20, Tedd Sterr wrote: >> For displaying coloured text on a badly contrasting background, e.g. >> white text on a white background, this can easily be handled >> intelligently by the receiving client:

Re: [Standards] [STANDARDS] XEP-0394: too weak to replace XEP-0071

On Fri, Mar 16, 2018, at 09:20, Tedd Sterr wrote: > For displaying coloured text on a badly contrasting background, e.g. > white text on a white background, this can easily be handled > intelligently by the receiving client: the client knows its own > background colour, so if receiving white

Re: [Standards] [STANDARDS] XEP-0394: too weak to replace XEP-0071

From: Standards on behalf of Sam Whited Sent: 15 March 2018 14:38 Subject: Re: [Standards] [STANDARDS] XEP-0394: too weak to replace XEP-0071 >> 4. Using different fonts, font sizes and colors, for the same as in 3 >> or as parts of

Re: [Standards] XEP-0394: too weak to replace XEP-0071

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

Re: [Standards] Private Data storage discrepancy

Hi,   although I can't give you a good answer here, this is probably related to the issue I mentioned during the Call for Experience.   It's unclear if a single pubsub item should contain only one bookmark or multiple. The one bookmark per item appraoch seems to be favoured by XEP-223: "the

Re: [Standards] XEP-0394: too weak to replace XEP-0071

Hi I'm the main dev of Salut à Toi Le vendredi 16 mars 2018, 10:08:12 CET Dave Cridland a écrit : > Neither Movim nor Salut à Toi etc need to stop using XHTML embedded > into XMPP (usually, in their case, via Atom). That's right, we both (Movim and SàT) use full XHTML (even if XEP-0277

Re: [Standards] Private Data storage discrepancy

Hi Guus, Thanks for the work on Bookmarks :) Indeed that was, I think, a mistake. On my side I followed the structure of the 0048 (https://github.com/movim/moxl/blob/master/src/Moxl/Stanza/Bookmark.php#L30) which, I think is more logical (the storage:bookmarks namespace is defined with this

Re: [Standards] XEP-0394: too weak to replace XEP-0071

Hello! 16.03.2018, 12:18, "Jonas Wielicki" :So, believe me that I can understand your frustration. In the discussion lastoctober (you’ll find it in the archives there, or see [0]), I was on the "noway we’re going to deprecate XHTML-IM in favour of a hack like '393" side,too. I

[Standards] Private Data storage discrepancy

Hello, I'm working on migrating Bookmarks ( https://xmpp.org/extensions/xep-0048.html) from Private XML Storage ( https://xmpp.org/extensions/xep-0049.html) to PEP ( https://xmpp.org/extensions/xep-0223.html). I'm was surprised to find a difference between the Pubsub node defined in 0048 example

Re: [Standards] XEP-0394: too weak to replace XEP-0071

On 16 March 2018 at 08:56, Kozlov Konstantin wrote: > Hello! > > 16.03.2018, 11:31, "Ненахов Андрей" : > > > btw, I'm new here, what were the reasons for deprecating XEP-0071 ? > > It's a new tradition here: deprecate XEP not because it is bad,

Re: [Standards] XEP-0394: too weak to replace XEP-0071

On 16 March 2018 at 07:37, Jonas Wielicki wrote: > On Donnerstag, 15. März 2018 19:19:30 CET W. Martin Borgert wrote: >> Quoting Jonas Wielicki : >> > If you are doing graphics/text design/publishing with your IM client, >> > you’re doing it wrong, in my

Re: [Standards] XEP-0394: too weak to replace XEP-0071

Hello! 16.03.2018, 11:31, "Ненахов Андрей" :btw, I'm new here, what were the reasons for deprecating XEP-0071 ?It's a new tradition here: deprecate XEP not because it is bad, but because there is a lot of bad implementations around.And a lot of bad implementations

Re: [Standards] XEP-0394: too weak to replace XEP-0071

>> Now someone else sends you contents of config file. It is processed >> with markdown. Oops. > Different problem, solvable by protocol level indicator that text should be > processed as markdown in the first place, and client-side controls whether > to include or honor the enablement tag. All

Re: [Standards] XEP-0394: too weak to replace XEP-0071

On Donnerstag, 15. März 2018 19:19:30 CET W. Martin Borgert wrote: > Quoting Jonas Wielicki : > > If you are doing graphics/text design/publishing with your IM client, > > you’re doing it wrong, in my opinion. > > But XMPP is not only IM. What about blogging or social