On Sun, Mar 29, 2009 at 12:42 AM, Hirsch, Richard < [email protected]> wrote:
> 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. I'm not sure that Rabbit would help a lot for behind-the-firewall scenarios. There are still trust issues behind the firewall... certain pools will only be federated to certain ESME instances... and thus trusting Rabbit to move those messages is a breakdown in the trust model (unless the messages are encrypted... then what's the point of Rabbit when we can just make an HTTP request on machines?) > > > 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. I'm thinking Rabbit as a sink (destination) for updates like the current email sink is in filters. I also view Rabbit as a source of updates. In both of these scenarios, Rabbit sits between ESME and external systems. > > > 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 > > > -- 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
