> On 5 Jun 2018, at 10:33, Guillaume Delhumeau <guillaume.delhum...@xwiki.com>
> wrote:
>
> Hi.
>
> The implementation is almost done, and is online on a branch:
> https://github.com/xwiki/xwiki-platform/tree/feature-user-messages-in-notifications.
>
>
> The good point is that it has forced me to improve our event descriptor
> mechanism (ie: adding the ability to disable a recordable event descriptor
> on some conditions), which could be useful.
>
> I think we all agree the "Message Sender" application has a lot of problems
> and should be replaced by something better, if we have the chance in the
> future.
>
> Now, I have just added what was missing to display them properly on the
> notifications (without too much work), since they are already present in
> the database. It means we can finally replace the AS by the notifications,
> which is a great achievement (and I congratulate myself for that). We are
> still aligned with our objectives to ensure retro-compatibility (old
> messages can still be read) and to not break functionalities (no
> regression).
>
> At the end, we could create a new proposal to decide what should be the
> future of the Message Sender, but I consider the current debate as closed
> (except if everybody want to put my work in the trash bin).
+1 to what you said and for the work you did.
It’ll be months (years?) before we have a better implementation of
messages/chat/inbox center so it’s good to have this for the few users who
might want to send messages to everyone, to a group or to someone (it’s off by
default).
Thanks Guillaume
-Vincent
>
> Thanks,
>
> Guillaume
>
>
> 2018-06-04 18:15 GMT+02:00 Eduard Moraru <enygma2...@gmail.com>:
>
>> Hi,
>>
>> (sorry for not reading the discussions above, I hope to get to read them at
>> some point)
>>
>> I just wanted to remind you that:
>> 1. We (at least I did) have previously concluded that it was a *mistake* to
>> mix notifications with messages.
>> 1.1 Notifications have transient lifecycle and can be easily discarded. The
>> previous ActivityStream implementation actually had a periodic
>> notifications/events cleaner that would automatically delete events older
>> than (e.g.) 30 days, for both storage and performance reasons.
>> 1.2 Messages have a much longer lifecycle, some users choosing to never
>> delete them and keep record of all conversations they ever had with
>> someone.
>> 1.3 Mixing storage for the 2 is a recipe for disaster, IMO, and, if/when we
>> plan to handle it seriously, we should either implement or integrate a
>> separate solution for messaging, both on the storage and the UI level. IMO,
>> the biggest intersection between Notifications and Messaging is the ability
>> to receive a notification about the fact that you have received a message
>> from X. Reading the message and acting upon it (i.e. replying, etc.) should
>> be done in the dedicated UI of the Messaging Application (i.e. inbox/etc.).
>>
>> 2. We *don't have to* and *shouldn't* keep all the features of the previous
>> system. Instead, this was supposed to be a good opportunity to improve on
>> our previous mistakes, not repeat them, in a new and improved system.
>>
>> 3. The Network/Follow feature is still a nice feature to stay up to date
>> with the activity of some users of interest. The "Send message to
>> followers", however, is, IMO, outside the scope of Notifications.
>>
>> 4. When talking about Messaging, we can also distinguish 2 types of
>> messages: public and private.
>> 4.1 Private messages should, IMO, necessarily be addressed with the
>> Messaging application detailed at 1. Also, private messages need to be
>> trustworthy, as they can/do usually contain sensitive information. The data
>> should not be deleted and it should be properly protected.
>> 4.2 Public messages, that have a more transient nature, could be the scope
>> of some "Announcements" application, that could behave as Notifications.
>> Couple that with the ability to interact with events (i.e. reactions or
>> comments on the page displayed under the event) and you get a very live and
>> social environment.
>>
>> Thanks,
>> Eduard
>>
>> On Thu, May 31, 2018 at 7:19 PM, Vincent Massol <vinc...@massol.net>
>> wrote:
>>
>>>
>>>
>>>> On 31 May 2018, at 18:07, Clément Aubin <aubincl...@gmail.com> wrote:
>>>>
>>>> On 05/31/2018 05:44 PM, Vincent Massol wrote:
>>>>>
>>>>>
>>>>>> On 31 May 2018, at 17:28, Clément Aubin <aubincl...@gmail.com>
>> wrote:
>>>>>>
>>>>>> On 05/31/2018 04:42 PM, Vincent Massol wrote:
>>>>>>
>>>>>> […]
>>>>>>
>>>>>>>> I'm here describing my own usage of collaborative platforms or
>> social
>>>>>>>> networks. If it wasn't supported before today, maybe we should
>> think
>>>>>>>> about it, because usually, people with only one friend to talk to
>> are
>>>>>>>> rare. Having multiple conversation is something that we should at
>>> least
>>>>>>>> think about.
>>>>>>>
>>>>>>> Did I say we should not think about it?
>>>>>>
>>>>>> Oh I'm sure that you didn't said that, but this would need a more
>>>>>> in-depth investigation, and not just 2 days of implementation.
>>>>>
>>>>> No no this is out of scope for now.
>>>>>
>>>>>>
>>>>>>> Also as I wrote you can send to a group and to everyone too so yes
>>> you can send to multiple people.
>>>>>>
>>>>>> I'm not talking about sending a message to groups, but to multiple
>>>>>> individuals.
>>>>>
>>>>> I know and out of scope for now.
>>>>>
>>>>>>
>>>>>>>> Also, as you mentioned it in the end of your previous mail, "if we
>> do
>>>>>>>> nothing now, nothing will happen for at least 1 year", what makes
>> you
>>>>>>>> think that we'll have the time to improve the feature later on,
>> even
>>> if
>>>>>>>> we do need it ?
>>>>>>>
>>>>>>> Ok so we have a big disagreement:
>>>>>>> * You say “displaying notifications in the proposed way is bad thing
>>> and there’s no use case for it”
>>>>>>
>>>>>> Please don't rephrase me like that :) . The current notifications
>> are,
>>>>>> IMO correctly displayed (and we're not debating about how to display
>>>>>> notifications AFAIK).
>>>>>
>>>>> Sorry I meant ‘displaying messages in the notifications UI in the
>>> proposed way is a bad thing and there’s no use case for it”
>>>>>
>>>>>> However, I don't think that the notification
>>>>>> center has been crafted to correctly display user messages. Merging
>>>>>> events coming from the wiki and messages coming from the message
>> stream
>>>>>> is tricky.
>>>>>
>>>>> Why? They’re both coming from the same location, i.e. event table…
>>>>
>>>> Mostly because user messages (as in private, user to user messages) can
>>>> be related from one to another (ie : the message B that you just sent
>> me
>>>> is a response from the message A that I sent you). You will then need
>>>> some context to display the response from someone in your notification
>>>> center. I don't think that we have an easy way to do that now.
>>>
>>> We could actually (since the event stream allows for 4-5 custom params).
>>>
>>> However, I wouldn’t do answers FTM (I don’t think we had this before
>>> either). Just ability to send messages.
>>>
>>>>
>>>>>>
>>>>>>> * I say “‘displaying notifications for those who want to send
>>> messages to a single person, to a group or to everyone is better than not
>>> being able to do it”.
>>>>>>>
>>>>>>> Also note that it’s disabled by default ATM so by default you get
>>> what you want, i.e. nothing!
>>>>>>
>>>>>> It's disabled by default for now, but it's actually proposed to
>> enable
>>>>>> it, else the proposal (2) would not make any sense.
>>>>>
>>>>> It’s not proposed FTM. Maybe you’re mixing the display of messages
>> when
>>> there are some with the messageSender macro usage on the dashboard?
>>>>
>>>> I'm talking about user messages as in [1] ; so private, user to user
>>>> messages.
>>>>
>>>>>> That also raises a problem : how can I be sure that you will be able
>> to
>>>>>> receive my message if I don't know in advance if you have enable or
>>>>>> disabled your ability to receive messages in your notification
>>> preferences ?
>>>>>
>>>>> The proposal Guillaume is implementing is to have them enabled by
>>> default.
>>>>>
>>>>> But indeed that could be refinement in the future that you can’t send
>>> messages to someone if they have disabled the reception. It’s out of
>> scope
>>> though.
>>>>>
>>>>>>
>>>>>> […]
>>>>>>
>>>>>>>> Yes, this is a feature that is also nice to have for all kind of
>>>>>>>> notification, however, this is what I mean by "shipping a half
>>> finished
>>>>>>>> feature" : messaging is something done in real time.
>>>>>>>
>>>>>>> Again we don’t agree about this. We’re not implementing a chat.
>> We’re
>>> implementing message sending as in email sending. Live message sending is
>>> another feature.
>>>>>>>
>>>>>>>> If you forget to
>>>>>>>> refresh your page, you forget to get new messages. Imagine if you
>>> had to
>>>>>>>> refresh a page every time you wanted to see a new message on IRC.
>>>>>>>
>>>>>>> This is exactly what you do with your email and I don’t think you
>> can
>>> say that email is useless…
>>>>>>
>>>>>> Ha ok, indeed, I didn't though about a non-live implementation of a
>>>>>> messaging system. IMO that's still something old (as nowadays, almost
>>>>>> every messaging system are live, even on forums and boards, that used
>>> to
>>>>>> propose this idea of personal messages a lot).
>>>>>
>>>>> email is old but the most used system :) So old doesn’t mean useful!
>>>>>
>>>>>> This could be an improvement idea if and only if we have an "inbox"
>> or
>>>>>> something in which we can put the messages that a user received in
>>> order
>>>>>> for him to check on them later.
>>>>>
>>>>> Yes notifications is an inbox for notifications. We have that already.
>>> you can even ack them.
>>>>>
>>>>>>
>>>>>> […]
>>>>>>
>>>>>>>> So we're putting back something that has been disabled by default
>>> since
>>>>>>>> more than one year without giving it enough features to be usable
>>> for a
>>>>>>>> standard user (things like being able to get messages in real time,
>>> for
>>>>>>>> example). For me, it's both a waste of time, and this might even
>>> degrade
>>>>>>>> the image of XWiki as it (IMO) won't be a very useful feature.
>>>>>>>
>>>>>>> I disagree with you and I’ve already explained in details the
>> reasons
>>> in a bullet point list.
>>>>>>>
>>>>>>>> I think that sending messages into the event stream was kind of a
>> bad
>>>>>>>> idea from the beginning as messages don't have the same "weight" as
>>>>>>>> other wiki events.
>>>>>>>
>>>>>>> The event stream has nothing to do with weight. It’s a timeline
>>> thing. It’s like saying: “having emails displayed in the order they are
>>> sent is a bad idea”.
>>>>>>
>>>>>> Using your example, you're not just displaying emails, you're also
>>>>>> displaying a ton of notifications about the documents that have been
>>>>>> updated in your wiki.
>>>>>
>>>>> We’re displaying notifications.
>>>>>
>>>>>>
>>>>>>> The way even stream events are displayed is an implementation
>> detail.
>>> They can be filtered, grouped, etc.
>>>>>>
>>>>>> I don't think that you should require a user to tune his notification
>>>>>> preferences in order not to be flooded by notifications. Having
>>> messages
>>>>>> is kind of a risk here because this implementation detail does not
>>>>>> protect the user enough from the messages hiding other important
>>> events.
>>>>>
>>>>> I don’t understand your point. Why would a user tune anything? A user
>>> simply says what notifications they’re interested in seeing.
>>>>>
>>>>> If they select too many then they’ll have the same issue you have with
>>> email :)
>>>>>
>>>>>>
>>>>>>>
>>>>>>>> I do understand that you don't like loosing features,
>>>>>>>> but since I've known XWiki, I've never heared of the Message Stream
>>> in a
>>>>>>>> good, useful and productive way.
>>>>>>>
>>>>>>> Then you shouldn’t care at all since it’s not going to be used and
>>> you’re not the one implementing it. It’s also off by default.
>>>>>>
>>>>>> See the beginning of my response.
>>>>>>
>>>>>>> So reading between the line, in the end you’re saying:
>>>>>>> * We shouldn’t have a messaging feature because what we need is a
>>> chat feature
>>>>>>
>>>>>> Actually, I don't think that a chat feature would be mandatory, but I
>>> do
>>>>>> think that it would be more attracting to people.
>>>>>>
>>>>>>> * There’s no way that people could use messages, it’s not useful
>>>>>>
>>>>>> I see some use cases for live messages, but I'm indeed having a hard
>>>>>> time seeing use cases for non-live messages as people can use another
>>>>>> chat tool aside from their wiki if we don't propose an "inbox"
>>> solution.
>>>>>>
>>>>>> It won't be reliable to send a message as :
>>>>>> * It can be filtered out by the recipient notification preferences
>>>>>> * It can be ditched in the bottom of the notifications of a user if
>> he
>>> /
>>>>>> she does not clean his / her notifications quickly enough
>>>>>> * There's no way to access this message once the notification center
>>> has
>>>>>> been cleared
>>>>>>
>>>>>>> What I’m saying:
>>>>>>> * We don't have chat feature and that’s a very large feature to
>>> develop with a completely different architecture.
>>>>>>
>>>>>> At least we agree on that :)
>>>>>>
>>>>>>> * A messaging feature is still interesting even if we have a chat
>>> feature one day. Example use case: "send a message to everyone that the
>>> xwiki will be be upgraded tomorrow”, “ notify a group of person to
>> review a
>>> document”, etc.
>>>>>>
>>>>>> Note that what you described are events and can actually be
>> implemented
>>>>>> using the event stream, so I'm not sure that those are correct
>>> examples.
>>>>>
>>>>> A message is an event for which the content is defined by the user.
>> Not
>>> sure what you mean.
>>>>
>>>> Not sure about what you mean too then … following your definition, [1]
>>>> is then a user message and [2] and [3] are not. At least, that's what I
>>>> understand as "user messages”.
>>>
>>> I was trying to understand what you meant by “Note that what you
>> described
>>> are events and can actually be implemented
>>> using the event stream, so I'm not sure that those are correct
>> examples.”.
>>>
>>> Messages *ARE* implemented using the event stream :)
>>>
>>> Thanks
>>> -Vincent
>>>
>>>>
>>>>>>
>>>>>>> * It costs little to be back to iso feature (1-2 days) and it’s
>>> taking almost the same amount of time just to discuss not doing it in
>> this
>>> thread ;)
>>>>>>
>>>>>> I don't like this idea as this is kind of discouraging the discussion
>>> on
>>>>>> features that we have to put in the platform ([1], especially "Ensure
>>>>>> agreement on the work being done (it's too stupid to do a lot of work
>>>>>> and only find when it's finished that it wasn't the right way to do
>> it
>>>>>> and it has to be all redone again)") ;)
>>>>>
>>>>> What? You lost me completely here.
>>>>>
>>>>> Why does it discourage discussions to implement something?
>>>>>
>>>>> If you’re interested in working on a chat system in xwiki, please
>> knock
>>> yourself up and start a proposal/discussion. Nobody is preventing you
>> from
>>> doing that.
>>>>>
>>>>> Thanks
>>>>> -Vincent
>>>>>
>>>>>>
>>>>>>> * I don’t see why messaging would be bad and affect the XWiki usage
>>>>>> negatively. Especially since message stream is off by default.
>>>>>>
>>>>>> See the beginning of my response.
>>>>>>
>>>>>>> Thanks
>>>>>>> -Vincent
>>>>>>
>>>>>> Thanks,
>>>>>> Clément
>>>>
>>>> [1]
>>>> http://design.xwiki.org/xwiki/bin/view/Proposal/
>>> UserMessageNotifications#HUserMessages
>>>> [2]
>>>> http://design.xwiki.org/xwiki/bin/view/Proposal/
>>> UserMessageNotifications#HUserMentions
>>>> [3]
>>>> http://design.xwiki.org/xwiki/bin/view/Proposal/
>>> UserMessageNotifications#HAppNotifications
>>>
>>>
>>
>
>
>
> --
> Guillaume Delhumeau (guillaume.delhum...@xwiki.com)
> Research & Development Engineer at XWiki SAS
> Committer on the XWiki.org project
