incubator-esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Pollak <feeder.of.the.be...@gmail.com>
Subject Re: Other twitter functionality to implement
Date Mon, 30 Mar 2009 17:17:38 GMT
On Sun, Mar 29, 2009 at 12:42 AM, Hirsch, Richard <
richard.hirsch@siemens.com> 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: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
>
>
>


-- 
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

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