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