This is quite a bit of work as it requires not just ad-hoc, admin script, but also some changes in the Tigase core code, in SM.

Pushed to the next version.

Andrzej, please estimate work effort for such functionality. Based on this we will decide for which version we want to implement it.

%kobit We have our custom message broadcast feature which delivers messages in specified time frame to every logged in user only once. I wonder if we could use it here and just add adhoc command which will use this message broadcast feature. If so, then it should be easy to implement.

I thought for a while about this approach too. However, this is completely different use-case. MOTD is not sent to all online users like a broadcast. It is a message which is sent to each user right away after he logins into the system and it is sent only no more than once a day. So the ad-hoc command would be only used to set the current MOTD on the server (ideally on all cluster nodes from a single command).

Therefore, I think it should/could/might be implemented in a completely different way. Maybe like kind of a processor which is executed somehow just after a user logins/binds resource/sends initial presence. However, I am not sure if processor would be the most efficient solution in this case. I think SM has some hooks for events like resource bind, initial presence, etc... which are used by the clustering strategy. Maybe MOTD could be executed from such a method or maybe from the presence plugin.

No, no, no. I mentioned "custom message broadcast" not regular adhoc based message broadcast.

I was considering usage of implementation from task #2247 - which states

implementation of broadcasting feature to allow broadcast of message to every resource of user which will connect before message expiration date

Looks exactly as MOTD description, right? If so, then we could just create adhoc which will register message for this AMP based broadcast. What do you think?

To be honest I am not sure. Maybe this is the same and we just describe it differently.

This is because "broadcast" for me is like "send to all currently online" or maybe even: "send to all, online or offline".

However, for me MOTD is not about broadcast at all. Let me describe how I see it work from the end-user/admin point of view.

1. We have a running XMPP system with some users online, some users offline and some users who do not even have accounts yet (technically they are not users yet) but will create accounts for them soon.

2. An admin sets a new MOTD on the system.

3. The new MOTD is NOT sent to anybody right away, in particular it is NOT sent to currently online users.

4. Only when a user logins to the system, the MOTD is sent to the user but no more than once a day.

5. I am not sure if the MOTD should be sent to a user for each of his resources or just once, to the first resource connecting during the day. This is a details which is not even important.

6. Also, when a new account is created and a new users logins to the system he also receives the MOTD as a normal user with long time account

A similar and also useful would be a "Welcome message". A message which is sent to users who just created an account on the system. Such a message would be sent only once to a user, just after the account is created and the first time the user logins to the system. So, if we have both implemented a new user would receive 2 messages after the first login: "welcome message" and MOTD.

Ok, so for now I think that use of custom message broadcast is not a good idea and may be an overkill in this case.

But we could use UserRepository to store date of last time motd was delivered for each user and add separate processor handling initial presence to send message to user. (We should use new presence processor as we need to send message to user after it sets priority as XMPP server should not send messages to clients with priority lower than 0).

And then separate adhoc script which would set MOTD in UserRepository to store for server between restarts. Additionally processor would keep this value in memory for faster access and in 7.2.0 we should have access from adhoc commands of SM to SM processors and could use this MOTD processor method to update this value. This should be good and "simple" solution from MOTD.

A similar approach we can do for JabberIqRegister processor. It can always send message to offline user which got created and this will be delivered to user after first connection and will work as a welcome message.

%kobit What do you think about this approach?

Yes, I like both suggestions, the one for MOTD and the one for Welcome message.

Feature is implemented and working properly. Propagation of changes in cluster is ensured using EventBus

However I would like a second opinion on how I store data directly to UserRepository in MotdProcessor and JabberIqRegister@. I wonder if this should be left as it is (direct access to instance of @UserRepository@) or if we should create some wrapper which will allow to access data only for @SessionManager (user_jid == "sess-man")

I really prefer if all the access to the repository/DB is done through XMPPResourceConnection object. There are methods for "setData" and similar which allow to access repository. If it is not possible, let me know.

%kobit Use of XMPPResourceConnection is not possible in this case.

• I need to store data for a component in a UserRepository implementation - not for a user (to store data for user I use @XMPPResourceConnection@)

• I need to read data in initialization time of a processor - no XMPPResourceConnection is avaialble

• I need to set data using method from processor called from AdHoc command script - no way to get instance if XMPPResourceConnection

So to sum up, my goal is to store data in UserRepository and in theory I could use ComponentRepository storing data in UA. However ComponentRepository is too complex for this task and too big and due to that I would like to have something different - ie. allow SM to inject instance of a new class which would allow us to store data in UserRepository but for a component (not for user). It would be same thing for a component as XMPPResourceConnection for a user data.

Currently I used UserRepository because it was already in place and available (thanks to Kernel framework and dependency injection).

Artur Hefczyc wrote:

If it is not possible, let me know.

Assigning to Artur as per above quote.

As for the issue - I concur Andrzej idea that we could/should extend plugin API to allow storing some generic/general/shared non-user data available to all users to avoid direct access to UserRepo instance.

Yes, of course, general MOTD management cannot be done through XMPPResourceConnection and I am fine with how it is done right now.

My remarks about XMPPResourceConnection were related to the piece of logic which ensures that MOTD is sent to a user no more than once a day. I thought we need to record in DB information when the MOTD was sent to a user last time, so every time it logins during the day he does not get the MOTD.

Yes, and for recording time of last MOTD delivery I'm using XMPPResourceConnection.

In this case we can close this issue or create new repository class for SM to make it possible to store informations related to component using this class rather that directly using @UserRepository@.

%kobit Let me know what you decide.