[Standards] UPDATED: XEP-0277 (Microblogging over XMPP)
binary at jrudevels.org
Wed May 23 07:21:22 UTC 2012
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
> > 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
> 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
> > 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:
> 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
> > on the topic.
> Agreed. Anyone else?
> Peter Saint-Andre
With best regards,
XMPP Developer and JRuDevels.org founder.
More information about the Standards