Why couldn't you just have a "deleted" attribute in the message object. Of course, then you have to define what happens when a deleted message is present in a conversation. Of course, you might have consider performance problems. D.
________________________________ Von: David Pollak [mailto:[email protected]] Gesendet: Mo 23.03.2009 16:42 An: [email protected] Betreff: Re: Other twitter functionality to implement On Mon, Mar 23, 2009 at 2:34 AM, Hirsch, Richard <[email protected] > wrote: > I was exploring the Twitter REST API and was comparing to what we > currently support. Although there is some functionality (favorites, > block, etc.), there are still some functionality that is open. > > What about supporting the deletion of messages? > > * statuses/destroy > Destroys the status specified by the required ID parameter. The > authenticating user must be the author of the specified status. > > I know this currently isn't possible in ESME but I think it is a > functionality that is useful. Of course, the inclusion of pools would > influence the future implementation (think of pools in which messages > can't be deleted based on compliance reasons) but until we have > developed pools, the deletion of messages would still be useful. > > Added a Jira item for this: > https://issues.apache.org/jira/browse/ESME-51 > > Thoughts? It makes life very difficult. I am an anti-fan of mutable messages. But there may be a way around it. Rather than deleting a message, have a separate table of non-displayed messages and the messages in that table are used as a filter for the messages in a mailbox. > > > D. > > -- Lift, the simply functional web framework http://liftweb.net <http://liftweb.net/> Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Git some: http://github.com/dpp
