Return-Path: Delivered-To: apmail-incubator-esme-dev-archive@minotaur.apache.org Received: (qmail 26653 invoked from network); 1 Oct 2009 15:18:53 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 1 Oct 2009 15:18:53 -0000 Received: (qmail 89292 invoked by uid 500); 1 Oct 2009 15:18:53 -0000 Delivered-To: apmail-incubator-esme-dev-archive@incubator.apache.org Received: (qmail 89244 invoked by uid 500); 1 Oct 2009 15:18:53 -0000 Mailing-List: contact esme-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: esme-dev@incubator.apache.org Delivered-To: mailing list esme-dev@incubator.apache.org Received: (qmail 89234 invoked by uid 99); 1 Oct 2009 15:18:53 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Oct 2009 15:18:53 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of feeder.of.the.bears@gmail.com designates 209.85.211.182 as permitted sender) Received: from [209.85.211.182] (HELO mail-yw0-f182.google.com) (209.85.211.182) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Oct 2009 15:18:40 +0000 Received: by ywh12 with SMTP id 12so321048ywh.21 for ; Thu, 01 Oct 2009 08:18:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :x-goomoji-body:date:message-id:subject:from:to:content-type; bh=hBqwiNgOxCAnsCfnIoqwJ88MZKIBHfn6rQpPN9qJTMk=; b=NNSKzlBiJH2buYSZfA5ytQ4sPBQLDFQMsNS5imF8xX4xG4RL86e8VbgMeC5CwSRRIz /XlqptwOW24sKpC7IQRM61ixLX5mcxcs2AzzFNCCRSVLz8z//Ux/rpAofaNnJphiMFjU hBaG+3mq4E6ansKicVFkoejzTXssABzNOE8CU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:x-goomoji-body:date:message-id :subject:from:to:content-type; b=SYpCyy1SNpASjuz93Aj//9erEDHS5kte8DaGBj/x9DgaieHtb5KGJXVRAEVLzKweZ5 d/S6W/En5g2B8zUc+45CxHbG5cxYYK/wyTreJd6YNna1h+bQYurzFuXuyHpXKhNSzbi3 cegXMgQ5q4iNmj8f16iz3i4A1QgnV0QYYTOn8= MIME-Version: 1.0 Received: by 10.90.45.19 with SMTP id s19mr730358ags.100.1254410297052; Thu, 01 Oct 2009 08:18:17 -0700 (PDT) In-Reply-To: <4db64d890910010118j3e548b64ide62829df9f6e376@mail.gmail.com> References: <4db64d890909302023n56114990s2e6197554e63a0ed@mail.gmail.com> <4db64d890910010037o15c7d7du785deb893852e15c@mail.gmail.com> <4db64d890910010118j3e548b64ide62829df9f6e376@mail.gmail.com> X-Goomoji-Body: true Date: Thu, 1 Oct 2009 08:18:16 -0700 Message-ID: Subject: Re: Deleting user from access pool From: David Pollak To: esme-dev@incubator.apache.org Content-Type: multipart/related; boundary=0016362847fc28955f0474e128e0 X-Virus-Checked: Checked by ClamAV on apache.org --0016362847fc28955f0474e128e0 Content-Type: multipart/alternative; boundary=0016362847fc28955a0474e128df --0016362847fc28955a0474e128df Content-Type: text/plain; charset=UTF-8 On Thu, Oct 1, 2009 at 1:18 AM, Xuefeng Wu wrote: > We can do this: message.setVisible(false) [?] > > This is mutating the message. The problem with mutations are two-fold: - Performance. Yeah, sure, with an RDBMS backing the timeline, it's costless. But if backing store changed to some form append-only logging (e.g. Cassandra), it becomes a lot more difficult to mutate messages. I've had some exposure to the pain involved with making the wrong decisions (e.g., assuming mutability of messages) and the costs when things get too big. - Federation. We cannot guarantee that the mutation takes place across a federated network. We have no control over the nodes and they may or may not delete the item. It's much like the Exchange/Outlook message deletion issue. It doesn't always work. What's worse, people expect it to work and when a message that has been "deleted" isn't, people get upset. > > On Thu, Oct 1, 2009 at 4:09 PM, Vassil Dichev wrote: > >> OK, I transitioned from talking about deleting messages from a mailbox >> to deleting messages from the DB, but you get the point. There are >> other actions, which are associated with receiving messages in a >> mailbox, which are not reversible- sending email, sending an http post >> request... >> >> I'm also using interchangeable mailbox, inbox and timeline here. >> >> >> On Thu, Oct 1, 2009 at 10:58 AM, Vassil Dichev >> wrote: >> > There are counterexamples- when you send out an email, it's in the >> > inbox of the people you have sent it to and you cannot delete it. When >> > you send a message in an instant messaging client, you cannot get it >> > back. In the context of JIRA, the item can still change after >> > permission is denied to you, while the message cannot be reedited in >> > ESME. >> > >> > I'm with Dick here. The performance problem is that the stream of >> > messages is updated in near real-time and any deleted messages will >> > cause a cascade of changes across the inboxes of all users who have >> > linked this message. >> > >> > I think we discussed deleting messages before, not in the context of >> > this pool, and David strongly favored the opinion that messages should >> > be immutable- once they're sent, that's it. Deleting messages also >> > poses security/consistency issues with possible federation scenarios, >> > which David intended to implement. >> > >> > There are many many other inconsistency issues which could arise if we >> > start deleting messages. Take for example, resending. If a resent >> > message is deleted, do you delete it from the inboxes of all your >> > followers? And if it's a popular resent message, do you delete it from >> > the stats actor? Do you reevaluate all the statistics for resent >> > messages then? What if the message contains tags, do you reevaluate >> > the tag cloud? What if it contains links, which are in the popular >> > links stats? What if the message is part of a conversation, do you >> > delete the whole conversation? >> > >> > So in the end, the immutability of messages and timelines is already >> > deeply ingrained in the ESME architecture and is not subject to >> > change- even if we decide that it's wise to do so, which I think it's >> > not. It's far from a trivial change. >> > >> > Vassil >> > >> > >> > On Thu, Oct 1, 2009 at 10:37 AM, Xuefeng Wu wrote: >> >> If user could not see any message from a pool which he/she leave, even >> >> his/her message, What will happen? >> >> In a company, If some one leave a team/project/department, he/she may >> be >> >> could not read any document even he/she write. >> >> >> >> The messages are also some resource for a team/project/department, I >> think >> >> it's fine that do not allow users can not read any messages in the >> pool. >> >> >> >> Think about jira, if you create a issue(task, defects) and the >> permission >> >> said only team members. >> >> And if you leave the team, you can not read the issue anymore. >> >> >> >> >> >> >> >> On Thu, Oct 1, 2009 at 12:51 PM, Richard Hirsch > >wrote: >> >> >> >>> Regarding the first part (deleting users from a pool) - here are my >> ideas >> >>> * We have no idea whether he has viewed the messages or not. >> >>> * Of course, he should be able to continue see his own messages even >> >>> if they were sent to a pool to which he no longer belongs. >> >>> * The user's messages remain in the pool whether or not the user is in >> the >> >>> pool. >> >>> * Since the user can no longer view the pool, he can only view his own >> >>> messages but not those of other users. >> >>> * Question: Should we delete all old messages from the pool to which >> >>> the user was a member or should we just prevent new messages from the >> >>> now-forbidden pool going to the user. I prefer the second choice. >> >>> >> >>> Thoughts? >> >>> >> >>> To the second point regarding the deletion of pools. I think this >> >>> needs more thought. We can't / shouldn't delete messages from closed >> >>> pools. This would be a performance and programming nightmare. >> >>> >> >>> D. >> >>> >> >>> On Thu, Oct 1, 2009 at 5:23 AM, Xuefeng Wu wrote: >> >>> > There're two features:1. delete users from pool; >> >>> > 2. delete pool. >> >>> > >> >>> > There're some argue and my opinion: >> >>> > *when delete users from pool.* >> >>> > We could withdraw all messages from the user, whatever read or >> unread. >> >>> > >> >>> > *when delete pool. ESME-68* >> >>> > withdraw all messages >> >>> > can create new pool which have the same name as deleted >> >>> > >> >>> > >> >>> > >> >>> > On Wed, Sep 30, 2009 at 3:59 PM, Vassil Dichev >> >>> wrote: >> >>> > >> >>> >> > Should we allow for a user to be deleted from an access pool? >> >>> >> > >> >>> >> > If yes what happens? Does he no longer have access to the >> messages in >> >>> >> > the pool - irregardless of whether he wrote them or not? >> >>> >> >> >>> >> It should be possible to delete a user, yes. I think it has been >> >>> >> discussed or specified in the requirements pdf that once a message >> is >> >>> >> in the user's mailbox, it stays there, so that's how it works now. >> At >> >>> >> any rate, deleting a message from the mailbox, which the user may >> have >> >>> >> already seen doesn't offer any more security. A user also doesn't >> see >> >>> >> messages in his/her mailbox, which were sent before he was added to >> >>> >> the pool. >> >>> >> >> >>> >> The interesting part is what happens if a pool has been removed and >> >>> >> whether it should be possible at all. This could pose a security >> >>> >> problem if an impostor creates a pool with the same name (similar >> to >> >>> >> what might happen with a deleted user account) >> >>> >> >> >>> > >> >>> > >> >>> > >> >>> > -- >> >>> > Global R&D Center,Shanghai China,Carestream Health, Inc. >> >>> > Tel:(86-21)3852 6101 >> >>> > >> >>> >> >> >> >> >> >> >> >> -- >> >> Global R&D Center,Shanghai China,Carestream Health, Inc. >> >> Tel:(86-21)3852 6101 >> >> >> > >> > > > > -- > Global R&D Center,Shanghai China,Carestream Health, Inc. > Tel:(86-21)3852 6101 > -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Surf the harmonics --0016362847fc28955a0474e128df Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Thu, Oct 1, 2009 at 1:18 AM, Xuefeng = Wu <benewu@gmail.c= om> wrote:
We can do this: message.setVisible(false)=C2=A0


This is mutating the messa= ge.

The problem with mutations are two-fold:
=
  • Performance. =C2=A0Yeah, sure, with an RDBMS backing the timel= ine, it's costless. =C2=A0But if backing store changed to some form app= end-only logging (e.g. Cassandra), it becomes a lot more difficult to mutat= e messages. =C2=A0I've had some exposure to the pain involved with maki= ng the wrong decisions (e.g., assuming mutability of messages) and the cost= s when things get too big.
  • Federation. =C2=A0We cannot guarantee that the mutation takes place acr= oss a federated network. =C2=A0We have no control over the nodes and they m= ay or may not delete the item. =C2=A0It's much like the Exchange/Outloo= k message deletion issue. =C2=A0It doesn't always work. =C2=A0What'= s worse, people expect it to work and when a message that has been "de= leted" isn't, people get upset.
=C2=A0

On Thu, Oct 1, 2009 at 4:09 PM, Vassil Dichev <vdichev@apache.org>= wrote:
OK, I transitioned from talking about deleting messages from a mailbox
to deleting messages from the DB, but you get the point. There are
other actions, which are associated with receiving messages in a
mailbox, which are not reversible- sending email, sending an http post
request...

I'm also using interchangeable mailbox, inbox and timeline here.


On Thu, Oct 1, 2009 at 10:58 AM, Vassil Dichev <vdichev@apache.org> wrote:
> There are counterexamples- when you send out an email, it's in the=
> inbox of the people you have sent it to and you cannot delete it. When=
> you send a message in an instant messaging client, you cannot get it > back. In the context of JIRA, the item can still change after
> permission is denied to you, while the message cannot be reedited in > ESME.
>
> I'm with Dick here. The performance problem is that the stream of<= br> > messages is updated in near real-time and any deleted messages will > cause a cascade of changes across the inboxes of all users who have > linked this message.
>
> I think we discussed deleting messages before, not in the context of > this pool, and David strongly favored the opinion that messages should=
> be immutable- once they're sent, that's it. Deleting messages = also
> poses security/consistency issues with possible federation scenarios,<= br> > which David intended to implement.
>
> There are many many other inconsistency issues which could arise if we=
> start deleting messages. Take for example, resending. If a resent
> message is deleted, do you delete it from the inboxes of all your
> followers? And if it's a popular resent message, do you delete it = from
> the stats actor? Do you reevaluate all the statistics for resent
> messages then? What if the message contains tags, do you reevaluate > the tag cloud? What if it contains links, which are in the popular
> links stats? What if the message is part of a conversation, do you
> delete the whole conversation?
>
> So in the end, the immutability of messages and timelines is already > deeply ingrained in the ESME architecture and is not subject to
> change- even if we decide that it's wise to do so, which I think i= t's
> not. It's far from a trivial change.
>
> Vassil
>
>
> On Thu, Oct 1, 2009 at 10:37 AM, Xuefeng Wu <benewu@gmail.com> wrote:
>> If user could not see any message from a pool which he/she leave, = even
>> his/her message, What will happen?
>> In a company, If some one leave a team/project/department, he/she = may be
>> could not read any document even he/she write.
>>
>> The messages are also some resource for a team/project/department,= I think
>> it's fine that do not allow users can not read any messages in= the pool.
>>
>> Think about jira, if you create a issue(task, defects) and the per= mission
>> said only team members.
>> And if you leave the team, you can not read the issue anymore.
>>
>>
>>
>> On Thu, Oct 1, 2009 at 12:51 PM, Richard Hirsch <hirsch.dick@gmail.com>w= rote:
>>
>>> Regarding the first part (deleting users from a pool) - here a= re my ideas
>>> * We have no idea whether he has viewed the messages or not. >>> * Of course, he should be able to continue see his own message= s even
>>> if they were sent to a pool to which he no longer belongs.
>>> * The user's messages remain in the pool whether or not th= e user is in the
>>> pool.
>>> * Since the user can no longer view the pool, he can only view= his own
>>> messages but not those of other users.
>>> * Question: Should we delete all old messages from the pool to= which
>>> the user was a member or should we just prevent new messages f= rom the
>>> now-forbidden pool going to the user. I prefer the second choi= ce.
>>>
>>> Thoughts?
>>>
>>> To the second point regarding the deletion of pools. I think t= his
>>> needs more thought. We can't / shouldn't delete messag= es from closed
>>> pools. This would be a performance and programming nightmare.<= br> >>>
>>> D.
>>>
>>> On Thu, Oct 1, 2009 at 5:23 AM, Xuefeng Wu <benewu@gmail.com> wrote:
>>> > There're two features:1. delete users from pool;
>>> > 2. delete pool.
>>> >
>>> > There're some argue and my opinion:
>>> > *when delete users from pool.*
>>> > We could withdraw all messages from the user, whatever re= ad or unread.
>>> >
>>> > *when delete pool. ESME-68*
>>> > withdraw all messages
>>> > can create new pool which have the same name as deleted >>> >
>>> >
>>> >
>>> > On Wed, Sep 30, 2009 at 3:59 PM, Vassil Dichev <vdichev@apache.org>= ;
>>> wrote:
>>> >
>>> >> > Should we allow for a user to be deleted from an= access pool?
>>> >> >
>>> >> > If yes what happens? Does he no longer have acce= ss to the messages in
>>> >> > the pool - irregardless of whether he wrote them= or not?
>>> >>
>>> >> It should be possible to delete a user, yes. I think = it has been
>>> >> discussed or specified in the requirements pdf that o= nce a message is
>>> >> in the user's mailbox, it stays there, so that= 9;s how it works now. At
>>> >> any rate, deleting a message from the mailbox, which = the user may have
>>> >> already seen doesn't offer any more security. A u= ser also doesn't see
>>> >> messages in his/her mailbox, which were sent before h= e was added to
>>> >> the pool.
>>> >>
>>> >> The interesting part is what happens if a pool has be= en removed and
>>> >> whether it should be possible at all. This could pose= a security
>>> >> problem if an impostor creates a pool with the same n= ame (similar to
>>> >> what might happen with a deleted user account)
>>> >>
>>> >
>>> >
>>> >
>>> > --
>>> > Global R&D Center,Shanghai China,Carestream Health, I= nc.
>>> > Tel:(86-21)3852 6101
>>> >
>>>
>>
>>
>>
>> --
>> Global R&D Center,Shanghai China,Carestream Health, Inc.
>> Tel:(86-21)3852 6101
>>
>



--
Global R&D Center,Shanghai China,Car= estream Health, Inc.
Tel:(86-21)3852 6101



--
Lift, the s= imply functional web framework http://liftwe= b.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dppSurf the harmonics
--0016362847fc28955a0474e128df-- --0016362847fc28955f0474e128e0--