[Standards] adding a human-readable field as RECOMMENDED for PEP-protocols?

Adam Nemeth aadaam at gmail.com
Sun Jun 17 20:13:44 CDT 2007


On 6/14/07, Peter Saint-Andre <stpeter at jabber.org> wrote:
>
>
> >
> > 3) Personally I'd like to see it through knotify/growl, and not a
> > message - since it would be hard to tell if user typed it in or it is
> > just automatic eventing from AmaroK. Example:
> >
> > http://jabbermania.blogspot.com/2007/05/general-pubsub-pep-receiver.html
> >
> > Look at the picture (mockup of knotify).
> >
> > Of course it's only my personal taste, but differentiating eventing
> > protocols from standard messages is a feature I believe.
>
> This gets back to something that Justin Karneges keeps mentioning. If
> you receive a message with a <body/> will your client just assume it's a
> regular old chat message? Probably. So then you're going to have all
> sorts of messages popping up "Adam is giving a presentation", "Oliver is
>   at the movies", "Peter is listening to Heart of the Sunrise" and so
> on, it will drive you crazy and you'll quickly curse the day you ever
> enabled that feature.
>
> Peter



I never insisted naming it <body>. What about <status>? Or <text>? Or
<pre-rendered>? Or basically anything else.

Basically I just want a fallback protocol for PEP-subprotocols. To use this
fallback protocol, one's client should still implement at least receiving
PEP notifications, but not necessarily all of the XEPs.

What would happen otherwise? Most of PEP-subprotocols would remain
unimplemented anyway, since there are too much of them. They differ in a
really small portion, the rendering would be mostly the same for User
Activity and User Tune: get those metadata, display a message like
printf("%s is %s
%s",publisher,activityverb,field1.toString()+field2.toString());
and put it out an identical way (in the roster display, in a notification
bubble near statusbar/system tray/kicker/panel etc).

Of course it could happen, that
- receiving user is not interested at all in a certain event
- receiving user is not interested in a specific user's certain event.

This would happen even if the client developer would painstakingly implement
all of the different eventing protocols one-by-one.

What I still insist, that most PEP-subprotocols would have a practically
near-identical receiving algorithm, and in a heterogenous client environment
(xmpp in the consumer market) it would help spread jabber if all the clients
supporting PEP in general would implicitly support all the PEP-protocols.
Otherwise, client developers wouldn't face a new protocol - XEP-0163 - to
implement, they would face a dozen, which would differ in two lines of code
each, so we end up the usual "did you get that?" "what?" "Which client do
you use?" "Not the same" "I'm sorry" dialogue :(

What do you think? Where am I wrong?

(Below are modified examples)

<message
    from='stpeter at jabber.org'
    to='maineboy at jabber.org'>
<event xmlns='http://jabber.org/protocol/pubsub#event'>

    <items node='http://jabber.org/protocol/tune'>
      <item id='bffe6584-0f9c-11dc-84ba-001143d5d5db'>
        <tune xmlns='http://jabber.org/protocol/tune'>
          <artist>Yes</artist>
          <length>686</length>
          <source>Yessongs</source>
          <title>Heart of the Sunrise</title>
          <track>3</track>
          <uri>http://www.yesworld.com/lyrics/Fragile.html#9</uri>
        </tune>
        <status>listening to Yessongs - Heart of the Sunrise</status>
      </item>
    </items>
  </event>
</message>


Result:

+------------------------------------------------+
| stpeter is                                     |
|listening to Yessongs - Heart of the Sunrise    |
|                                                |
|<Block all such  notifications>                 |
|<Block such from stpeter>                       |
+------------------------------------------------+

-- 
Aadaam <aadaam at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.jabber.org/pipermail/standards/attachments/20070618/5175735c/attachment.html


More information about the Standards mailing list