Brion Vibber wrote:
The UI presentation can be worked out... my main worry is that this
just doesn't do what I'd expect "forwarding" to do.
Let's judge the implementation by the design criteria, though. The goal
isn't to make "forwarding" work, but to clone Twitter's retweet
functionality. Maybe 'repost' would be a better name than 'forward'?
'Redistribute'?
It looks like we've got a major problem with our mainstream methods of
reading, though, because notices you've gotten via forwarding appear
in the timeline according to their original posting date, not when
they were forwarded:
That was a bug in the implementation. It only happened when you didn't
have memcached enabled; it works the same now, with or without.
Further, your forwards won't make it all to any of these places:
* Local subscribers reading via XMPP
* Local subscribers reading via SMS
* OMB remote subscribers
I think our design goal would require that these happen. Clearly this
is what's meant by "send this notice out to my subscribers". However,
it's going to be tough to do; all our code to push out to these channels
* Twitter bridge
* Facebook bridge
* your profile timeline
* your profile's RSS or Atom feed
These, I'm not so sure. Since a reposted notice is not really "your"
notice, I don't think it makes sense to have reposts show up in your
timeline. However, looking at Twitter, that's what they do, at least for
the Web interface.
It also looks like they create a distinct status ID for each retweet.
This would be problematic for us; we'd either need to let these reposts
show up in the public stream (and other public places, like search
results, tag streams, and groups) or filter them out. Both are problematic!
It may make sense to do something like Twitter does: push out to feeds,
Twitter, and Facebook with the "RT " prefix (or something analogous --
sprintf(_("RT %s"), $notice->content)).
* your "and friends" timeline if you're subscribed to the original poster
Yeah, that's an interesting one. Should the same notice show up twice,
if you've already received it? Once for the original post, and once for
the first repost? Or should it show up once for every repost, even if
there are hundreds?
If we want to stick with it for compat with Twitter's new ReTweet, we
might want to give it a clearer name (probably the main reason that
it's been so controversial is that it's conceptually totally different
from the forwarding that people have been doing manually under that
name).
I think the implementation issues are not insuperable.
But there's a product planning question here that's pretty important,
though. On Identi.ca, at least, I'm exposed to a lot of comparisons
between our software and Twitter's. "When will StatusNet support
retweets?" It seems like a high priority from my perspective to at least
match the functionality of Twitter.
But that might not be a high priority for our actual admins and users.
What I'd like to do is this: let's push this reposting implementation
into a plugin. We can experiment with it for a while, and see if it
shapes up into thing that works for Twitter-like retweets. If it does,
we can make a project decision on whether and how to merge it back into
core. If it doesn't, we can do something else.
-Evan
--
Evan Prodromou
CEO, StatusNet, Inc.
[email protected] - http://identi.ca/evan - +1-514-554-3826
_______________________________________________
StatusNet-dev mailing list
[email protected]
http://lists.status.net/mailman/listinfo/statusnet-dev
