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?
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.
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).
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. 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)
P.S. thanks Peter for your review, I glad if some discussion will appear
on the topic.
Peter
