I'm not really proposing altering the existing standard, because it
works fine for several tasks. It seems it would be just a matter of scope.
I know users writing commands looks weird, but we should consider that
they will probably be using different clients at the same time and they
would prefer doing the same in all of them. Anyway I just mean launching
applications. Once they are launched, forms would take place in order to
enter data.
El 18/10/2016 a las 9:43, Dave Cridland escribió:
On 18 October 2016 at 08:11, jorge - w <jwien...@gmail.com> wrote:
I'm just trying to receive feeback from the community, since i have recently
joined it.
Sure - and it's appreciated.
In order to avoid client dependency, any programming should be done at
server side. I already know anything can be coded with no need for a
standard, I'm just exposing an idea, not a personal need.
Protocol designs that need no special support from the client are
really powerful - but they also have limitations.
We can encode almost everything as text, but XEP-0050 encodes any
command (or command sequence) as a series of form exchanges. It's not
quite as good, in as much as clients do need support for XEP-0050, but
they don't need any special support for any particular command.
On a similar note, MUC (XEP-0045) encodes everything using existing
exchanges of directed presence and messages. That's served us
incredibly well over the years, but it's also brought us into a
dead-end.
There's a balance to be made here.
But just as we think '45 can be improved, I'm open to the idea of '50
being improved or replaced too - but I'd like to see a concrete
design. Write something more formal, and ideally submit it as a XEP,
and we can compare the options side-by-side much better.
El 18/10/2016 a las 8:59, Kevin Smith escribió:
On 18 Oct 2016, at 07:54, jorge - w <jwien...@gmail.com> wrote:
My view is that XEP-0050 is fine as an admin tool, just like XEP-0133.
But what is fine for admins is not always the same for regular users.
That's why i think there should be a different interface for regular users
mostly aimed to external applications. Users might prefer :app_short_name to
launch them without the need for extra menus.
This seems to be conflating user interface with protocol, there’s nothing
stopping clients from doing parsing for :something in the text field and
turning it into adhocs behind the scenes.
That said, if this is something you believe is needed, the usual thing to
do is to write up a protoXEP and see what support it gets in the
community/Council.
/K
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
_______________________________________________
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
_______________________________________________
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
_______________________________________________
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
_______________________________________________
