Hate to bug the mailing list with this, but I spent several hours going through the code & Google, and I'm stumped.
I'm running 0.8.4, I'm trying to get the Kolab calendar plugin working because it looks pretty slick. Latest version of that available for download seems to be v0.7.4, except for a v3.0.1. I can't tell which one (if either) is correct for 0.8.4, but 3.0.1 complained immediately about a missing rcube class, so I fell back to 0.7.4 which mostly works (after you copy the skins in from v3.0.1).
The only problem it seems to be having is that no notifications are going out for events. I would assume that it needs to be tied in to some kind of cron job (or...?), but I don't see a reasonable-looking candidate for that, nor have I been able to sort out how the notifications system is supposed to work. I see events being added to the events table in MySQL, everything looks reasonable there, but I can't find anything responsible for handling them once they're in there.
What am I missing? The docs are pretty thin. I'd be happy to help with either code / documentation if necessary.
Thanks,
Rob Sheldon wrote:
Hate to bug the mailing list with this, but I spent several hours going through the code & Google, and I'm stumped.
I'm running 0.8.4, I'm trying to get the Kolab calendar plugin working because it looks pretty slick. Latest version of that available for download seems to be v0.7.4, except for a v3.0.1. I can't tell which one (if either) is correct for 0.8.4, but 3.0.1 complained immediately about a missing rcube class, so I fell back to 0.7.4 which mostly works (after you copy the skins in from v3.0.1).
First of all, there's no officially working and tested version of the calendar plugin for 0.8. You should go for the latest version of both Roundcube (0.9-beta) and the plugin. This is also what is shipped as part of the recently released Kolab 3.0 stable edition.
The only problem it seems to be having is that no notifications are going out for events. I would assume that it needs to be tied in to some kind of cron job (or...?), but I don't see a reasonable-looking candidate for that, nor have I been able to sort out how the notifications system is supposed to work. I see events being added to the events table in MySQL, everything looks reasonable there, but I can't find anything responsible for handling them once they're in there.
What kind of notifications do you expect? The only notification type supported by the plugin is "display" which will only pop-up in active sessions of Roundcube. But the triggering mechanism in Roundcube changed from 0.8 to 0.9 and as I just mentioned above, the plugin is made for the 0.9 release of Roundcube and things might not work correctly with 0.8.
In addition to that, the 'libcalendaring' plugin is now running the notification system (both for calendar and tasks). So make sure you also downloaded and installed that plugin from the Kolab repositories.
Furthermore, this plugin was developed for the use with the Kolab backend and the database backend isn't fully tested.
Regards, Thomas
On 2013-01-20 5:21, Thomas Bruederli wrote:
First of all, there's no officially working and tested version of the calendar plugin for 0.8. You should go for the latest version of both Roundcube (0.9-beta) and the plugin. This is also what is shipped as part of the recently released Kolab 3.0 stable edition.
OK, I'll do that this Friday night -- our usual time for server upgrades.
What kind of notifications do you expect? The only notification type supported by the plugin is "display" which will only pop-up in active sessions of Roundcube. But the triggering mechanism in Roundcube changed from 0.8 to 0.9 and as I just mentioned above, the plugin is made for the 0.9 release of Roundcube and things might not work correctly with 0.8.
v0.7.4 of the calendar plugin seems to offer "Email" as a notification method in all of its dialogs (and setting "Email" as the notification method in an appointment seems to show up correctly in the MySQL backend). Maybe this disappeared in 3.0? That would be a shame, email works nicely as a notification method, especially for smartphone users.
In addition to that, the 'libcalendaring' plugin is now running the notification system (both for calendar and tasks). So make sure you also downloaded and installed that plugin from the Kolab repositories.
Alright ... I feel like an idiot here, but it seems that GitHub has changed its interface recently, and I can't find a download link for this anywhere. Do I need to set up and install git to fetch this? I can do that, no big deal, I've just never used it before. (Still stuck on svn.) I'd rather not spend the time on that if I don't have to though.
Furthermore, this plugin was developed for the use with the Kolab backend and the database backend isn't fully tested.
FWIW, I didn't find anything that seemed broken by the MySQL backend. But thanks for the heads-up, I'll test it thoroughly.
Thanks Thomas.
Hi Rob,
why don't you get yourself a Kolab Server instead of trying to fiddle everything together manually?
On Monday 21 January 2013 15:08:14 Rob Sheldon wrote:
In addition to that, the 'libcalendaring' plugin is now running the notification system (both for calendar and tasks). So make sure you also downloaded and installed that plugin from the Kolab repositories.
Alright ... I feel like an idiot here, but it seems that GitHub has changed its interface recently, and I can't find a download link for this anywhere.
libcalendering can be found here:
https://kolab.org/about/libcalendaring
Regards, Torsten
Hi Torsten,
On 2013-01-22 1:21, Torsten Grote wrote:
Hi Rob,
why don't you get yourself a Kolab Server instead of trying to fiddle everything together manually?
That's a fair question. I did look at Kolab before posting my question, I like the project, there's certainly demand for great open source groupware, and I hope it continues to grow and do well. There are a few reasons I'm not jumping into it right now:
do offer benefits, but there are also common drawbacks: updates to individual components tend to get held up by other components (and updates in general eventually become a big hairy mess as the project architecture changes), at some point the architecture gets too big for any one developer to get their brain around and spooky bugs start showing up, and once you're locked in to one, it can be really hard to change your mind later and move on to something else. As I have it now, each piece of the server stack is neatly compartmentalized, so I can deal with e.g. SpamAssassin issues separately from Dovecot issues, and if I decide I'd like to give DBMail a try, then I can.
already been framed into the sort of Enterprise-y documentation that will require several days of my time to fully digest. For example, the current documentation for deployment preparation: http://docs.kolab.org/en-US/Kolab_Groupware/3.0/html/Deployment_Guide/chap-D... (Just two headings, "Loading the LDAP Schema" and "System Users", followed by only "Para" for filler text.) Other parts of the documentation look good, so I have no doubt you guys will get this taken care of soon.
pretty clear advantages to that, but a major downside is severe resource constraints. At this time I can't figure out how many users I could support on Kolab with just 1G RAM.
gradually become a subset of a larger project, and I think there are other people who will have reasons for not wanting to switch to something like Kolab (or Horde). For those people, and me, and my customers, I think a slick calendar plugin for RoundCube would be a huge bonus, and if I can do one little thing for the RoundCube project by getting the calendar plugin up and working and fully production tested against a MySQL backend, along with a howto or other documentation afterwards, I'd like to do that.
If you'd like to discuss it further, I'd be happy to do so off-list.
libcalendering can be found here:
https://kolab.org/about/libcalendaring
Awesome, thank you!
Hi Rob,
On Tuesday 22 January 2013 02.01:59 Rob Sheldon wrote:
- I'm wary of relying on Really Huge Packages Of Stuff.
That's understandable and in fact I think you'll find we agree.
It is why Kolab has deliberately been designed as a set of components that can see individual upgrade & replacement with rolling releases. ;)
- I'm working on building services in VPS environments. There are
pretty clear advantages to that, but a major downside is severe resource constraints. At this time I can't figure out how many users I could support on Kolab with just 1G RAM.
About the same number of users you could support with Roundcube.
Typical bottlenecks for Kolab are the IMAP server (and disk I/O for that) and the actual client usage, so the number of people connected to the web frontend or the ActiveSync connector if you are offering that.
- And finally, I really dig the RoundCube project, I'd hate to see it
gradually become a subset of a larger project, and I think there are other people who will have reasons for not wanting to switch to something like Kolab (or Horde).
Understood, and agreed.
But I think may have a somewhat skewed picture of Kolab if you think it bears similarity to Horde. And just because Kolab is also working intensively with Cyrus IMAP, for instance, that does not mean Cyrus is becoming a sub-project of Kolab any more than Apache has been a sub-project of Roundcube.
In the end it's a network of communities that work together, and we've been extremely careful to leave all the design decisions to the Roundcube community, and help where we can to move things forward.
Much like anyone else who contributes to Roundcube, although you are of course right that we've contributed a lot over the past years and I understand that can also be cause for concern.
I'm just not sure what else we could be doing to dispell those concerns, to be honest. Contributing less seems a bad option in which everyone loses.
In the end it boils down to trust.
The people who are involved in Kolab have long careers in Free Software, and are known to be good citizens in our community. Building these reputations took us years and we can only offer our own credibility and encourage people to work with us to find out for themselves.
For those people, and me, and my customers, I think a slick calendar plugin for RoundCube would be a huge bonus, and if I can do one little thing for the RoundCube project by getting the calendar plugin up and working and fully production tested against a MySQL backend, along with a howto or other documentation afterwards, I'd like to do that.
Calendaring is a complex beast. More complex than people realize, typically.
It only gets really useful once you have the whole sharing & ACLs figured out, the whole invitation handling over email and of course the nightmares that are posed by time zones and platforms that do not respect some of the standards.
Some of that is present in the Roundcube Calendaring modules, but other functionality comes from the underlying Kolab libraries. You are of course welcome to write new libraries that do the same thing. Chances are the end result would be a lot of work, and support fewer users on a VPS, though.
There are benefits to forking and parallel evolution, of course.
But there are also benefits to collaboration.
So if you wanted to work together, you'd be very welcome.
Best regards, Georg
On 2013-01-21 15:08, Rob Sheldon wrote:
On 2013-01-20 5:21, Thomas Bruederli wrote:
First of all, there's no officially working and tested version of the calendar plugin for 0.8. You should go for the latest version of both Roundcube (0.9-beta) and the plugin. This is also what is shipped as part of the recently released Kolab 3.0 stable edition.
OK, I'll do that this Friday night -- our usual time for server upgrades.
Just did the 0.9-beta upgrade, plugins upgrade, and installed 3.0.1 of the calendar plugin; still no notifications (display or otherwise). I've gotta get a little sleep, I'll poke it this weekend and see if I can figure out what's going on. Everything in the DB looks kosher when an appointment is set up. Dates & times are all (amazingly!) correct.
In addition to that, the 'libcalendaring' plugin is now running the notification system (both for calendar and tasks). So make sure you also downloaded and installed that plugin from the Kolab repositories.
Point of confusion here: you seem to refer to a libcalendaring _plugin_, which is included with the 3.0.1 kolab plugins package. What's provided from the Kolab repositories is a libcalendaring library (C/C++ code) which seems to be for KDE integration. I assume that's not what you mean?
Thanks,
Rob Sheldon wrote:
On 2013-01-21 15:08, Rob Sheldon wrote:
On 2013-01-20 5:21, Thomas Bruederli wrote:
First of all, there's no officially working and tested version of the calendar plugin for 0.8. You should go for the latest version of both Roundcube (0.9-beta) and the plugin. This is also what is shipped as part of the recently released Kolab 3.0 stable edition.
OK, I'll do that this Friday night -- our usual time for server upgrades.
Just did the 0.9-beta upgrade, plugins upgrade, and installed 3.0.1 of the calendar plugin; still no notifications (display or otherwise). I've gotta get a little sleep, I'll poke it this weekend and see if I can figure out what's going on. Everything in the DB looks kosher when an appointment is set up. Dates & times are all (amazingly!) correct.
In addition to that, the 'libcalendaring' plugin is now running the notification system (both for calendar and tasks). So make sure you also downloaded and installed that plugin from the Kolab repositories.
Point of confusion here: you seem to refer to a libcalendaring _plugin_, which is included with the 3.0.1 kolab plugins package.
I'm referring to http://git.kolab.org/roundcubemail-plugins-kolab/tree/plugins/libcalendaring which provides some common, calendaring-related functions used by both the calendar and the tasklist plugin. It hooks into the 'refresh' hook triggered by Roundcube (version >= 0.9-beta) and collects notifications from the calendar plugin. The frequency of those refresh triggers can be set in the Settings > User Interface > Main Options section of Roundcube. Make sure you don't set it to 'never'.
What's provided from the Kolab repositories is a libcalendaring library (C/C++ code) which seems to be for KDE integration. I assume that's not what you mean?
That's something else and only relevant if you're using the Kolab server backend.
~Thomas
On 2013-01-27 8:48, Thomas Bruederli wrote:
I'm referring to http://git.kolab.org/roundcubemail-plugins-kolab/tree/plugins/libcalendaring which provides some common, calendaring-related functions used by both the calendar and the tasklist plugin.
OK. At a glance, that seems to be identical to what's included in roundcubemail-plugins-kolab-3.0.1.tar.gz from git.kolab.org. Is this correct?
The frequency of those refresh triggers can be set in the Settings > User Interface > Main Options section of Roundcube. Make sure you don't set it to 'never'.
Hah, I had just noticed that the automatic inbox refreshes seemed to have stopped. I think you just saved me some time, thank you.
On 2013-01-27 18:26, Rob Sheldon wrote:
On 2013-01-27 8:48, Thomas Bruederli wrote:
I'm referring to http://git.kolab.org/roundcubemail-plugins-kolab/tree/plugins/libcalendaring which provides some common, calendaring-related functions used by both the calendar and the tasklist plugin.
OK. At a glance, that seems to be identical to what's included in roundcubemail-plugins-kolab-3.0.1.tar.gz from git.kolab.org. Is this correct?
Yes.
Naturally bug-fixes go in to the roundcubemail-plugins-kolab-3.0 branch[1], which we'll issue a release for now and then, in the form of a 3.0.2, 3.0.3, etc.
Also, further development occurs in the master branch[2], which is both more bleeding edge and (thus) less stable.
If you look at the two links I'm sure you'll find the 3.0 branch is just a little ahead of the 3.0.1 release, and master is quite a bit further ahead of both the 3.0 branch and therefore also the 3.0.1 release.
Kind regards,
Jeroen van Meeuwen
[1] http://git.kolab.org/roundcubemail-plugins-kolab/log/?h=roundcubemail-plugin... [2] http://git.kolab.org/roundcubemail-plugins-kolab/log/?h=master