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)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_001_01C9B041.F40D00F2"
Subject: RE: Other twitter functionality to implement
Date: Sun, 29 Mar 2009 09:42:47 +0200
Message-ID: 
 <30DB6ACF50A0A3439F39EFEB1C52E166078F23BD@nets13ja.ww300.siemens.net>
Thread-Topic: Other twitter functionality to implement
Thread-Index: Acmu3B4knxS4oj6DSm6PioNyvRpBmABZO1GI
References: 
 <22478227.2091591237999592528.JavaMail.servlet@kundenserver><cdbebedf0903250958m2d5c6bbal812c9fe26f20867d@mail.gmail.com><68f4a0e80903251017i4699b394j5f31f0e5ad39871c@mail.gmail.com><30DB6ACF50A0A3439F39EFEB1C52E16607D68786@nets13ja.ww300.siemens.net>
 <cdbebedf0903270600m159726a6t8d7d35a2f83a4567@mail.gmail.com>
From: "Hirsch, Richard" <richard.hirsch@siemens.com>
To: <esme-dev@incubator.apache.org>

------_=_NextPart_001_01C9B041.F40D00F2
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

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.
=20
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.=20
=20
D.=20

________________________________

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=FCngliche Nachricht-----
> Von: Ethan Jewett [mailto:esjewett@gmail.com]
> Gesendet: Mittwoch, 25. M=E4rz 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=3Dtrue" 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=3Dtrue" 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/>=20
> > > >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/>=20
> > 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/>=20
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp


------_=_NextPart_001_01C9B041.F40D00F2--