Mailing-List: contact esme-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: esme-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of vdichev@gmail.com designates
 209.85.219.205 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:sender:in-reply-to:references:date
         :x-google-sender-auth:message-id:subject:from:to:content-type;
        b=guwRmWdNXBrT9VgHRMSULanNMBlpJbvdX9C3RHj+72Ja3+I4Z53c6dCxHcflOKMcRD
         LOxtVP0Wmo1qc9+SeO5yg3J7Vg5vP5Lck+lVuHlBL8QSJZSLOZEFKB1AyMQ4c4k5isZ7
         WK5i2dgZPpOrJbuYHfMqIuSNxuka/LT60S3sA=
MIME-Version: 1.0
Sender: vdichev@gmail.com
In-Reply-To: <c7fc82820910010058p1a3d3e9ejf6428104d5b5cb04@mail.gmail.com>
References: <fa2d9f450909300000k1dfb07eerfadd4ed15f122ad2@mail.gmail.com>
	 <c7fc82820909300059w72306b7es36cee99464f1debd@mail.gmail.com>
	 <4db64d890909302023n56114990s2e6197554e63a0ed@mail.gmail.com>
	 <fa2d9f450909302151v31cfcf1dn53674dd4b00d80bf@mail.gmail.com>
	 <4db64d890910010037o15c7d7du785deb893852e15c@mail.gmail.com>
	 <c7fc82820910010058p1a3d3e9ejf6428104d5b5cb04@mail.gmail.com>
Date: Thu, 1 Oct 2009 11:09:17 +0300
Message-ID: <c7fc82820910010109q576bd1ffi5b85f91a09990167@mail.gmail.com>
Subject: Re: Deleting user from access pool
From: Vassil Dichev <vdichev@apache.org>
To: esme-dev@incubator.apache.org
Content-Type: text/plain; charset=ISO-8859-1

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
> 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 <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 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 <hirsch.dick@gmail.com>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 <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 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 <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 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
>>
>