Mailing-List: contact esme-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: esme-dev@incubator.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-Id: <22478227.2091591237999592528.JavaMail.servlet@kundenserver>
From: Darren Hague <dhague@fortybeans.com>
To: <esme-dev@incubator.apache.org>
Subject: Re: Other twitter functionality to implement
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Date: Wed, 25 Mar 2009 17:46:32 +0100

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.

Cheers,
Darren

>On Wed, Mar 25, 2009 at 7:56 AM, Hirsch, Richard <richard.hirsch@siemens.com
>> 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:feeder.of.the.bears@gmail.com]
>> Gesendet: Mo 23.03.2009 16:42
>> An: esme-dev@incubator.apache.org
>> Betreff: Re: Other twitter functionality to implement
>>
>>
>>
>> On Mon, Mar 23, 2009 at 2:34 AM, Hirsch, Richard <
>> richard.hirsch@siemens.com
>> > 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


-- 
darren.hague@fortybeans.com