Excellent analysis. On Thu, Oct 1, 2009 at 6:48 AM, Ethan Jewett <[email protected]> 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 <[email protected]> > 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 <[email protected]> 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 <[email protected] > >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 <[email protected]> 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 <[email protected]> > >>> 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 <[email protected]> > 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 < > >>> [email protected] > >>> >> >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 <[email protected]> > 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 < > [email protected] > >>> > > >>> >> >> 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
