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 <[email protected]> > 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 <[email protected] <mailto: > [email protected]>> > > > > 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. > >
