Thank you![?] On Fri, Oct 2, 2009 at 1:11 AM, David Pollak <[email protected]>wrote:
> On Thu, Oct 1, 2009 at 9:49 AM, Xuefeng Wu <[email protected]> wrote: > > > I have a question about HTML element id.Where I write the element's id > > attribute value? in code or Html? > > > > For example, I want add a feature to edit the pool's name. > > > > I have these snippet code: > > > > > def reDraw(*id*: String, content: NodeSeq) = SetHtml(id, content) > > > > def poolName(ap: AccessPool): NodeSeq = > > > swappable(<span>{ap.getName}</span> , > > > > <span>{ajaxText(ap.getName, > > > > v => {ap.setName(v); ap.save; reDraw("*pool_name_id*", > > > <span>{ap.getName}</span>)})} > > > > </span>) > > > > > > As you see, I need the html element id value and reDraw . > > In my opinion, the html attribute* id *is about business model and > logical, > > I should write the value at server side. > > > > But if I write these: > > > > > def poolName(ap: AccessPool): NodeSeq = > > > swappable(<span>{ap.getName}</span> *% ("id" -> "pool_name_id"),* > > > > <span>{ajaxText(ap.getName, > > > > v => {ap.setName(v); ap.save; reDraw("pool_name_id", > > > <span>{ap.getName}</span>)})} > > > > </span>) > > > > swappable(<span id="pool_name_id">{ap.getName}</span>, ...) > > And then: > > reDraw("pool_name_id", Text(ap.getName)) > > SetHtml puts stuff inside the element with the given id. You're not > over-writing the span. > > > > > > > > Something will be wrong when user want to edit again without refresh the > > page. > > > > *Is there any suggestion?* > > > > > > On Fri, Oct 2, 2009 at 12:07 AM, David Pollak < > > [email protected] > > > wrote: > > > > > On Thu, Oct 1, 2009 at 9:05 AM, Xuefeng Wu <[email protected]> wrote: > > > > > > > If the pool is deleted.We need not do anything for the messages and > > > prevent > > > > user send message into the pool. > > > > > > > > That's all? > > > > > > > > > > I think so. > > > > > > > > > > > > > > On Thu, Oct 1, 2009 at 11:27 PM, David Pollak < > > > > [email protected] > > > > > wrote: > > > > > > > > > On Thu, Oct 1, 2009 at 2:05 AM, Anne Kathrine Petterøe < > > > > > [email protected] > > > > > > wrote: > > > > > > > > > > > I think we should stick with: > > > > > > > > > > > >> once a message is > > > > > >> in the user's mailbox, it stays there. > > > > > >> > > > > > > as we have agreed upon earlier. No need to delete sent messages. > > > > > > A user should be able to read old messages, as he had the > > permissions > > > > to > > > > > do > > > > > > so when they were sent. > > > > > > As Dick suggested this morning: "should we just prevent new > > messages > > > > from > > > > > > the > > > > > > now-forbidden pool going to the user." << this option has my > vote. > > > > > > > > > > > > I think a far more important is what happens if a pool is > removed? > > > And > > > > if > > > > > > yes, what happens if someone later creates a pool with the same > > > name? > > > > > > > > > > > > > > > > If a pool is deleted, the messages in the users timeline stay, but > it > > > is > > > > as > > > > > if all the users were deleted from the pool. > > > > > > > > > > Pools should not be name-dependent (sorry, I don't remember the > > current > > > > > implementation). They should have a GUID (think federation) so > that > > > the > > > > > internal access to the pool is via GUID. Thus, you can change the > > name > > > > of > > > > > the pool. You can delete the pool and create another with the same > > > name. > > > > > You could conceivably (I don't know if this is a good idea from a > > > > > user-perspective) create many pools with the same name. > > > > > > > > > > > > > > > > > > > > > > /Anne > > > > > > > > > > > > > > > > > > On 1. okt. 2009, at 10.33, Vassil Dichev wrote: > > > > > > > > > > > > Mail to a mailing list or IRC are not very private. > > > > > >> > > > > > >> Not sure I see the use case here. The user has already read this > > > > > >> message. If the team lead didn't want the user to ever read the > > > > > >> message, why add the user to the pool in the first place? > > > > > >> > > > > > >> Anyway, here's the design specifications document: > > > > > >> > > > > > >> http://groups.google.com/group/esme-dev/files > > > > > >> > > > > > >> > > > > > >> On Thu, Oct 1, 2009 at 11:21 AM, Xuefeng Wu <[email protected]> > > > wrote: > > > > > >> > > > > > >>> mail and IM is private but pool is public or group own. > > > > > >>> If a team leader create a pool, does he want people who leave > > pool > > > > > could > > > > > >>> read old message? > > > > > >>> I do not think so. > > > > > >>> > > > > > >>> 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 > > > > > >>> > > > > > >>> > > > > > > > > > > > > > > > > > > > > > -- > > > > > 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 > > > > > > > > > > > > > > > > > > > > > -- > > > > 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 > > > > > > > > > > > -- > > 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 > -- Global R&D Center,Shanghai China,Carestream Health, Inc. Tel:(86-21)3852 6101
