On 1/5/11 3:24 AM, Andrea Messina wrote:
I'm going to list some (major and minor) issues raised during Ostatus
testing of Status.Net account:
1) Salmon signature does not complain with the spec [Magic Signature]:
http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-magicsig-00.html
I'm going to poke at the sig issue shortly...
Status.Net replies are all MENTIONS. Afterwards, all the mentions are
incorporated in the profile feed and sent throw Pubsubhubbub and
Salmon!! (bandwidth overhead!!!!)
PuSH deliveries will *only* go to sites that subscribe to your feed,
while Salmon deliveries for replies/mentions are sent directly to
whoever is mentioned.
In theory we could detect at least a subset of cases where it would be
unnecessary to send the Salmon ping because we know the message will
come over PuSH, but it's not going to be a huge bandwidth savings.
Expect that sometimes you'll get duplicate message delivery (you might
get this too if, say, a PuSH delivery comes through but your
confirmation response doesn't reach the server, and it sends it again;
or when accepting messages over both individual and group feeds).
I have noticed that if i send a Post using pubsubhubub and then i
send the corresponding reply, still using pubsubhubbub and not Salmon;
Status.Net does not incoporate the two messages in the same conversation.
The actual post processing paths are the same through both PuSH and
Salmon inputs (Ostatus_profile::processPost()), so there should be no
difference between PuSH-based and Salmon-based delivery.
It looks like the conversation hookup on receive is currently based on
on having a <thr:in-reply-to ref="..."> which matches an existing notice
URI recorded in the local database. (The <ostatus:conversation> is
actually not yet fully used.)
(Note there can be both 'ref' and 'href' attributes; 'ref' is the one
that matters here, and it should match the replied-to post's entry/id.)
3) Status.Net conversation aren't fragmented ONLY in the SOURCE. I think
it would be nice to have the same conversation replicated to all the
Followers....For instance, we could reach this behaviour, incorporating
the replies post(local and remote) in the source atom feed and
delivering them using pubsubhubbub.
Could be fun to test things along those lines. :D
It probably requires going back and fetching old data, though, which
could be tricky -- a destination server may not have been participating
in the conversation until a thousand posts after the beginning.
-- brion
_______________________________________________
StatusNet-dev mailing list
StatusNet-dev@lists.status.net
http://lists.status.net/mailman/listinfo/statusnet-dev
