RE Rabbit: I'm a little confused now. I thought the idea was to use Rabbit for federation scenarios. What about the idea of using Rabbit for federation scenarios behind the firewall. Trust shouldn't be an issue in such scenarios. If we are talking about the use of Rabbit in Internet-based scenarios, are you suggesting that Rabbit as means to relay non-federated traffic coming from other data sources (not ESME servers). This is the impression I get from your email from 03/19. D.
________________________________ From: David Pollak [mailto:[email protected]] Sent: Fri 27.03.2009 14:00 To: [email protected] Subject: Re: Other twitter functionality to implement On Fri, Mar 27, 2009 at 1:21 AM, Hirsch, Richard <[email protected] > wrote: > The use of RabbitMQ might change the problem with deleting messages that > are located in a federated environment. Using Rabbit as a federation mechanism is a bad idea. Rabbit is best used when you can trust all the parties accessing the message queue. That is not true across the Internet. > I could send notification to the federated network that a ESME message is > being deleted and then those systems that have the message could act > accordingly. Of course, this would require some sort of message id that is > unique across all ESME servers. A GUID will be part of the messages (if it's not already). And yes, you can broadcast a "delete message with GUID" message to all the machines in your federation. It does not, however, deal with the "which mailbox did a message get into?" That is a harder problem because of filters. It's also an issue of what a user expects when they delete a message. They expect that the message will go away immediately. It may be many minutes before the message is removed from all the federated systems. I am super non-keen on deletion overall. Like email, once you hit sent, the message exists is the way I'd prefer to let users view ESME. Thanks, David > > > D. > > -----Ursprüngliche Nachricht----- > Von: Ethan Jewett [mailto:[email protected]] > Gesendet: Mittwoch, 25. März 2009 18:18 > An: [email protected] > Betreff: Re: Other twitter functionality to implement > > Case in point - the OpenMicroBlogging protocol that La.coni.ca supports > doesn't appear to allow for deletion of messages sent to federated sites. > http://openmicroblogging.org/protocol/0.1/ > > It appears that while La.coni.ca itself supports deletion of messages. > This > would have no effect on messages posted to federated systems unless they > were only displayed as a link to the originating system (which the protocol > doesn't appear to require). > > Sounds like a pretty hard problem. > > Ethan > > On Wed, Mar 25, 2009 at 11:58 AM, David Pollak < > [email protected]> wrote: > > > 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/> < > > > >> 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 > > > ><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 > > <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 <http://liftweb.net/> Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Git some: http://github.com/dpp
