On Wed, Mar 25, 2009 at 9:46 AM, Darren Hague <[email protected]> wrote:
> I think there's a distinction to be made here between mutable objects and > mutable data - or are you saying that SQL UPDATE is inherently evil? ;-) > > To preserve object immutability, a copy of the message object with > "deleted=true" could be created, and this could replace the previous message > in people's mailboxes as a side-effect of the method which updates the > message record in the database. Put another way, a mailbox which receives a > "deleted=true" message would cause a matter/antimatter-like annihilation of > the original message. Knowing which mailboxes a particular message made it to, especially in a federated system is a non-trivial task. > > > Cheers, > Darren > > >On Wed, Mar 25, 2009 at 7:56 AM, Hirsch, Richard < > [email protected] > >> wrote: > > > >> 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. > > > > > >Because a deleted attribute would mean mutating the message to add the > >attribute. > > > > > >> > >> > >> 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 > >> > >> > >> > > > > > >-- > >Lift, the simply functional web framework http://liftweb.net > >Beginning Scala http://www.apress.com/book/view/1430219890 > >Follow me: http://twitter.com/dpp > >Git some: http://github.com/dpp > > > > -- > [email protected] > -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Git some: http://github.com/dpp
