[Standards] UPDATED: XEP-0277 (Microblogging over XMPP)
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
> > >>>
> > >>> Abstract: This specification defines a method for microblogging
> > >>> 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.
> > > it option is excess but ejabberd implementation (for example) has
> > > default value of 10 which is too small for such application and it
> > > 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
> > implies that the default value is unreasonable. That might depend on
> > implementation and deployment (e.g., if someone runs an XMPP
> > to an existing microblogging service, or a dedicated XMPP-based
> > microblogging service, then the defaults might be perfectly
> > Thus I don't think the SHOULD is necessary here. It could say "verify
> > that the max items setting is reasonable for microblogging purposes
> > change if necessary".
> > >> Why change "pubsub#send_last_published_item" to "never"?
> > >
> > > Actually, just to prevent extra traffic from possible rich content
> > > items. Can be omitted but I think that such things would be better
> > > change on the client side but current Pubsub doesn't allow such
> > > interaction which is another problem. (I really wonder why such
> > > 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
> > > 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
> > > But the main idea is to provide an ability to retrieve it quickly.
> > > example, if I see a link to some comment for a some thread in
> > > 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
> > > 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...
More information about the Standards