I would suggest "repeat". Repost hints at it becoming a complete new entry. But AFAICS the real function is merely adding a link to a post from s/o else.
So the function is to repeat sth. in the sense of amplifying or spreading. Jan -- Jan H Wildeboer | EMEA Open Source Affairs | Office: +49 (0)89 205071-207 Red Hat GmbH | Mobile: +49 (0)174 33 23 249 Technopark II, Haus C | Fax: +49 (0)89 205071-111 Werner-von-Siemens-Ring 11 -15 | 85630 Grasbrunn | _____________________________________________________________________ Reg. Adresse: Red Hat GmbH, Technopark II, Haus C, Werner-von-Siemens-Ring 11 -15 85630 Grasbrunn, Handelsregister: Amtsgericht Muenchen HRB 153243 Geschaeftsfuehrer: Brendan Lane, Charlie Peters, Michael Cunningham, Charles Cachera _____________________________________________________________________ GPG Key: 3AC3C8AB Fingerprint: 3D1E C4E0 DD67 E16D E47A 9564 A72F 5C39 3AC3 C8AB ----- Original Message ----- From: [email protected] <[email protected]> To: [email protected] <[email protected]> Sent: Tue Dec 08 21:41:14 2009 Subject: Re: [StatusNet-dev] Forward (retweet) support 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 _______________________________________________ StatusNet-dev mailing list [email protected] http://lists.status.net/mailman/listinfo/statusnet-dev
