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")
