We can do this: message.setVisible(false) [?] On Thu, Oct 1, 2009 at 4:09 PM, Vassil Dichev <[email protected]> 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 <[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
