[Standards] UPDATED: XEP-0277 (Microblogging over XMPP)

Tim edhelas at gmail.com
Wed May 23 07:31:42 UTC 2012


Considering that the 0277 implement the Atom standard, can we continue to
follow the Atom Media system (http://specs.mart.me.uk/atommedia#anchor20)
or it's better to wait for a more clean XEP for this issue ?

2012/5/23 Sergey Dobrov <binary at jrudevels.org>

> On 05/23/2012 01:38 PM, Tim wrote:
> > Is there something planned to replace the removed "Attaching file to a
> > post" part ?
> > There was no clear explanation for this change.
>
> There are two problems with the feature:
>
> 1) this feature is too early: we have no solutions for some very
> important problems to think about such features as file attachments
> 2) the feature was too highly specialized: it did not describe HOW files
> should be served meaning HTTP storage but no any client can easily store
> (and maybe read too) to HTTP, we have to think how it can be done in
> more flexible manner first. (And it's a complicated problem too. For now
> my implementation (http://b.habahaba.im/) has a feature of pictures and
> files storage but it receive them via Stream Initiation and put on HTTP
> storage, anyway it needs clarification).
> 3) I think that it's too excessive to describe each feature Atom gave us
> in the XEP. (The feature consisted in just addition of a link to a post).
>
> >
> > Jaussoin Timothée
> >
> > 2012/5/22 Peter Saint-Andre <stpeter at stpeter.im <mailto:
> stpeter at stpeter.im>>
> >
> >     On 5/22/12 12:40 PM, Sergey Dobrov wrote:
> >     > On 05/23/2012 12:55 AM, Peter Saint-Andre wrote:
> >     >> On 5/22/12 11:56 AM, XMPP Extensions Editor wrote:
> >     >>> Version 0.6 of XEP-0277 (Microblogging over XMPP) has been
> released.
> >     >>>
> >     >>> Abstract: This specification defines a method for microblogging
> over
> >     >>> XMPP.
> >     >>>
> >     >>> Changelog: Added node configuration suggestions; removed file
> >     >>> attachments; added rich content examples; change atom:content to
> >     >>> atom:title anywhere in the document; invented the "Aggregator"
> >     >>> entity; changed nodes metainformation locations; added
> >     possibility to
> >     >>> add own content to repost. (snd)
> >     >>
> >     >> A few questions...
> >     >>
> >     >> What is a reasonable value for pubsub#max_items?
> >
> >     To be clear, this is in reference to the section on microblog node
> >     configuration:
> >
> >     http://xmpp.org/extensions/xep-0277.html#microblog_node_config
> >
> >     > It actually depends on server restrictions or user preferences.
> Maybe,
> >     > it option is excess but ejabberd implementation (for example) has
> >     > default value of 10 which is too small for such application and it
> can
> >     > be dangerous not to warn developers about such thing. AFAIK,
> >     Jappix sets
> >     > this value to something like 10-100 thousands of items which seems
> >     > reasonable.
> >
> >     Well, the need to *change* it from the default to some reasonable
> value
> >     implies that the default value is unreasonable. That might depend on
> >     implementation and deployment (e.g., if someone runs an XMPP
> interface
> >     to an existing microblogging service, or a dedicated XMPP-based
> >     microblogging service, then the defaults might be perfectly
> reasonable).
> >     Thus I don't think the SHOULD is necessary here. It could say "verify
> >     that the max items setting is reasonable for microblogging purposes
> and
> >     change if necessary".
> >
> >     >> Why change "pubsub#send_last_published_item" to "never"?
> >     >
> >     > Actually, just to prevent extra traffic from possible rich content
> of
> >     > items. Can be omitted but I think that such things would be better
> to
> >     > change on the client side but current Pubsub doesn't allow such
> >     > interaction which is another problem. (I really wonder why such
> things
> >     > as retractions delivery is set on a node level and not on client
> >     side).
> >
> >     But I certainly might want to receive the last published item
> whenever I
> >     log in. This too seems like a setting that a dedicated microblogging
> >     service would tune in their configuration.
> >
> >     >> I don't understand the special meaning of ItemID = zero for
> >     metadata. I
> >     >> think there might be a better way to handle this.
> >     >
> >     > The meaning is just to provide easy way to obtain this very
> important
> >     > data by just retrieving some magic constant named item.
> >
> >     We usually try to avoid magic values. :)
> >
> >     > It can be some
> >     > more adjective string like "meta", actually, it doesn't really
> matter.
> >     > But the main idea is to provide an ability to retrieve it quickly.
> For
> >     > example, if I see a link to some comment for a some thread in
> generic
> >     > pubsub service, I might be able to know which was the original
> >     post this
> >     > comment related to and then I can just retrieve that metadata node
> and
> >     > see and retrieve original post then. I don't want to create another
> >     > pubsub node for metadata because this will make our data even more
> >     sparse.
> >     >
> >     > Maybe, we can solve this using existing metadata pubsub feature
> >     but from
> >     > my point of view it's not too useful to store such data. (fix me
> if I
> >     > wrong)
> >
> >     In XEP-0084, we had a dedicated metadata node:
> >
> >     http://xmpp.org/extensions/xep-0084.html
> >
> >     That spec is not so widely implemented, but the model seems fine.
> >
> >     > P.S. thanks Peter for your review, I glad if some discussion will
> >     appear
> >     > on the topic.
> >
> >     Agreed. Anyone else?
> >
> >     Peter
> >
> >     --
> >     Peter Saint-Andre
> >     https://stpeter.im/
> >
> >
> >
>
>
> --
> With best regards,
> Sergey Dobrov,
> XMPP Developer and JRuDevels.org founder.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20120523/02544e28/attachment.html>


More information about the Standards mailing list