CSH wrote:
So, generally I wanted to doubt the validity of OF-478 and also the current behavior (at least it can be switched off with xmpp.muc.skipInvites=true, I saw).
Just reproduced this accidentally with Instantbird client (didn’t worked with Spark). Will have to set that property to true just in case. Can be disturbing while playing with user permissions.
wroot wrote:
And last one. I’m glad you take this, but i never meant to obligate you to do this Just posted it here as this post is relevant. Just shooting tickets into a wild as i often do
Lol, no… I see value in this for my company as well, but I have to do it on my time because mgmt doesn’t see value in it… (it’s one of those things that until you have it, you don’t really see the value).
I think the actual scheduling aspect won’t be difficult, however I’m still in the “exploritory” stage and am still figuring out how best to integrate this without disrupting existing features. Scheduling will be offloaded to the Quartz library as it handles scheduling things (in your local time) very well. The only problem is persistence of the schedule, so that we don’t lose scheduled conferences when a user exits spark or it crashes. Quartz has some nice ways to save the schedule in a database, but I don’t want to integrate this into openfire’s database and each spark having a database is overkill for one feature i think. so, i’m going to need to investigate serializing the quartz scheduling object and hope I can save it’s state that way with no issues.
I do agree, a separate ticket is probably best for this. Added SPARK-1577
Wonder, can’t Private Data Storage be used for storing schedules?
It could be possible… the quartz library wants it’s own database tables to use… but, if the scheduler object (the quartz JobStore) agrees with me serializing it (have not tested this yet), then it’s entirely possible that object could be saved on the server via Private Data Store… but, this would essentially be the same as storing it in the users %APPDATA% directory… basically a file (the serialized object) written to disk somplace is what’s needed, so that on spark launch, we can look for this file, deserialize it and use it.
Oh, nevermind. I somehow thought it would work without Spark running (sending invites) But that would also involve doing something non-standard with Openfire.
that could be done, but it would have to be either natively integrated into OF, or done as a plugin for OF. otherwise, spark will need to be running for it to send out the invites on the schedule.
oh, i get what you were saying… ie. a user “registers” a scheduled conference and then openfire sends the invites on the schedule…
hmm… could be done too… but also would require an OF plugin + a Spark plugin… and some non-standard communication between the 2…
i decided to do a native integration into spark instead of a plugin so that i can avoid doing funny stuff to the actions menu, in order for the “Schedule a conference” button to appear in the same grouping as the other conference buttons, otherwise adding a button to that menu via a plugin will, by default, add it to the bottom of the list… making it feel out of place.