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 feeder.of.the.bears@gmail.com
 designates 209.85.210.174 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=H1AdzQVidrLI2HwcgSGy9UNSh2h6JLJJZRLax31XbnMqSL/aHUS4PuOi+VTZW/XFH5
         vhNRYADmteSkhcBiTdCWzsmZVftysFZZmnYqo+PA7Q9tOIydEOgt6GisCoTbn73eG/n2
         WdhHtH0mIxjcW4eeZ+5Th0kjIqNobCxicwb5M=
MIME-Version: 1.0
In-Reply-To: <68f4a0e80910010648x5b6e1130oaa178d9f2cda65d0@mail.gmail.com>
References: <fa2d9f450909300000k1dfb07eerfadd4ed15f122ad2@mail.gmail.com>
	 <4db64d890909302023n56114990s2e6197554e63a0ed@mail.gmail.com>
	 <fa2d9f450909302151v31cfcf1dn53674dd4b00d80bf@mail.gmail.com>
	 <4db64d890910010037o15c7d7du785deb893852e15c@mail.gmail.com>
	 <c7fc82820910010058p1a3d3e9ejf6428104d5b5cb04@mail.gmail.com>
	 <4db64d890910010339m64f516d5p7c362f38c5a3f97f@mail.gmail.com>
	 <fa2d9f450910010354o519c1542wb83a4ce986eb50b8@mail.gmail.com>
	 <4db64d890910010425n7b3f6ae6nd0cc820e3167ba59@mail.gmail.com>
	 <fa2d9f450910010430k6dc2259fo5ddaeb6701f51479@mail.gmail.com>
	 <68f4a0e80910010648x5b6e1130oaa178d9f2cda65d0@mail.gmail.com>
Date: Thu, 1 Oct 2009 08:18:10 -0700
Message-ID: <cdbebedf0910010818l6a418287y972a962a1de67058@mail.gmail.com>
Subject: Re: Deleting user from access pool
From: David Pollak <feeder.of.the.bears@gmail.com>
To: esme-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=00163628375acce9ae0474e12734

--00163628375acce9ae0474e12734
Content-Type: text/plain; charset=UTF-8

Excellent analysis.

On Thu, Oct 1, 2009 at 6:48 AM, Ethan Jewett <esjewett@gmail.com> wrote:

> I agree with this (for what it's worth). From an end user perspective
> I think of my view of the historic timeline as immutable. I would be
> very confused if a message or whole conversation disappeared from that
> timeline and orphaned related messages and conversations.
>
> I think leaving old messages in the user timeline and not adding new
> messages from the pool is the right behavior.
>
> That said, what if a user has a significant role-change within a
> company? For example, the user goes from being an employee to being a
> supplier (and suppliers use the same ESME instance). In this case the
> company would probably not want the user to be able to access old
> messages on the server. But in this case it is really a matter of the
> company not wanting the user to be able to access the old
> timeline/account at all. The company would create an entirely new
> account for the user.
>
> In that case, I think the use-case is covered as well, by the user
> management side of the house.
>
> Ethan
>
> On Thu, Oct 1, 2009 at 7:30 AM, Richard Hirsch <hirsch.dick@gmail.com>
> wrote:
> > Yes. That is easier. We don't have to worry about existing messages in
> > the message queues and we just have to prevent future messages from
> > the now probited pool from going to the user.
> >
> > On Thu, Oct 1, 2009 at 1:25 PM, Xuefeng Wu <benewu@gmail.com> wrote:
> >> It well be easy ?
> >> If we do not whether user read or unread, just leave the message in
> his/her
> >> mailbox and could read whenever.
> >>
> >> And we never sent message to a user who leave the pool?
> >>
> >> On Thu, Oct 1, 2009 at 6:54 PM, Richard Hirsch <hirsch.dick@gmail.com
> >wrote:
> >>
> >>> The team leader would have no idea whether the user had read the
> >>> message or not. The assumption is that the user has read it. The user
> >>> was also part of the pool when the message was created - thus, at this
> >>> particular point in time, he actually did have the right to view the
> >>> message.
> >>>
> >>>
> >>>
> >>> On Thu, Oct 1, 2009 at 12:39 PM, Xuefeng Wu <benewu@gmail.com> wrote:
> >>> > mail and IM is private but pool is public or group own.
> >>> > If a team leader create a pool and does he want that some people who
> >>> leave
> >>> > team could red old message?
> >>> >
> >>> > On Thu, Oct 1, 2009 at 3:58 PM, 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
> >>> >> >
> >>> >>
> >>> >
> >>> >
> >>> >
> >>> > --
> >>> > 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

--00163628375acce9ae0474e12734--