incubator-esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hirsch, Richard" <richard.hir...@siemens.com>
Subject RE: Other twitter functionality to implement
Date Sun, 29 Mar 2009 07:42:47 GMT
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:feeder.of.the.bears@gmail.com]
Sent: Fri 27.03.2009 14:00
To: esme-dev@incubator.apache.org
Subject: Re: Other twitter functionality to implement



On Fri, Mar 27, 2009 at 1:21 AM, Hirsch, Richard <richard.hirsch@siemens.com
> 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:esjewett@gmail.com]
> Gesendet: Mittwoch, 25. März 2009 18:18
> An: esme-dev@incubator.apache.org
> 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 <
> feeder.of.the.bears@gmail.com> wrote:
>
> > On Wed, Mar 25, 2009 at 9:46 AM, Darren Hague <dhague@fortybeans.com>
> > 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 <
> > > 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/>
 <
> > > >> 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
> > >
> > >
> > >
> > > --
> > > darren.hague@fortybeans.com
> > >
> >
> >
> >
> > --
> > 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



Mime
  • Unnamed multipart/mixed (inline, None, 0 bytes)
View raw message