On 09/02/2011 01:22 AM, Sergey Dobrov wrote:
On 09/01/2011 03:21 AM, Justin Karneges wrote:
On Wednesday, August 31, 2011 11:32:53 AM Sergey Dobrov wrote:
IMO, the commenting approach described in XEP-277 is too simple and
rather
uninspired (full disclaimer: I work at a company whose sole product is
commenting). Commenting is similar, but not identical to
microblogging, and
the two deserve separate specs. Probably the commenting section in
XEP-277
should be exchanged with a pointer to XEP-303.
I reviewed the XEP-303 and I'm sorry that I did not that before since it
has some really significant notices, so I'll do some notes below and
maybe you are right with a pointer to XEP-303.
Anyway, are you saying that all of the functional requirements of XEP-303
could be extracted out into separate smaller "reusable" extensions that
implementors of generic XEP-60 servers might embrace? Really ejabberd
might
add an extension that mirrors VCards content in Atom entries? I guess in
theory that would be cool, but it seems a bit on the dreamy side.
I meant that common cases should be in XEP-60 or some other XEPs that
will describe some specific node behavior. For example, I don't sure
that this is ok to include filters into the node name (why to url quote
these?), but it can be useful to determine some queries protocol which
can be inserted in the request of items, so we can use generic pubsub
nodes without some functionality.
Then, my questions about XEP-303:
1) Why to use three nodes? Info node can be replaced by some item with
some constant id. about necessity of activity node I don't understood at
all, why to have it?
2) Why to use Activity Streams here? I totally misunderstanding why to
have such complication since commenting behavior totally get into simple
Atom format.
3) You have filter parameter by parent id but have no any mechanism to
represent such relations. But this mechanism is already defined in XEP-277.
4) atom:id MUST be an URI.
5) Again, why to url encode a node name?
("comments?order=-created&parent_ids=1%2C5a%2Co19g%2C")
I forgot about one thing: I think that this is unnecessary to validate a
sender on server side. That is why: I wrote a blog importer from the
juick.com microblogging service to my implementation of the XEP-277
based service and when it imports comments it uses fake JIDs but the
service sends publisher attribute so it can be validated who exactly
sent a comment but it's also possible to make such imports or another
pretty things. So I think that validation is unnecessary but publisher
attribute usage must be clarified more strictly in the XEP-60.
