Hey Roundcube community!
We at audriga are working on a JMAP PHP library which we plan on using in Roundcube. The main use-case we have in mind is to expose Roundcube's Contact and Calendar data over a JMAP API. What we are implementing should of course be extensible for Mail as well. We already managed to implement a PoC for Roundcube to read and write data over JMAP and want to contribute our changes upstream. Since will be our first time contributing to Roundcube, it would be great to get some initial feedback or guidance.
Considering there were some thoughts put into JMAP support in the past (for Roundcube Next concepts): Do you have any advice on extending Roundcube with this feature? Could a Roundcube plugin be the way to go?
Regards,
Joris
On 01.02.2021 17:00, Joris Baum wrote:
We at audriga are working on a JMAP PHP library which we plan on using in Roundcube. The main use-case we have in mind is to expose Roundcube's Contact and Calendar data over a JMAP API.
What do you mean expose? Are you up to a JMAP server or client?
should of course be extensible for Mail as well. We already managed to implement a PoC for Roundcube to read and write data over JMAP and want to contribute our changes upstream. Since will be our first time contributing to Roundcube, it would be great to get some initial feedback or guidance.
Considering there were some thoughts put into JMAP support in the past (for Roundcube Next concepts): Do you have any advice on extending Roundcube with this feature? Could a Roundcube plugin be the way to go?
Yes, plugin is the way to go, but a lot of core changes might be needed.
If it was for replacing IMAP store with JMAP store for mail, I'd suggest using undocumented storage_driver option. This would require writing a storage handler class that inherits from rcube_storage. By default rcube_imap is doing this. Of course this will be only a start. The core is not really prepared to work with different engine. All data structures are imap-based and not really standardized.
If you're up to using JMAP server as a source of contacts or calendar, then it would be separate plugins, I suppose. They could use/require the common "jmap_storage" plugin you create. For contacts this should be reasonably easy. For calendar you'd have to integrate into an existing calendar plugin (I assume) which will require some changes in that plugin's code.
On 02.02.21 08:50, Aleksander Machniak wrote:
What do you mean expose? Are you up to a JMAP server or client?
Thanks for your quick reply! We want Roundcube to act as a JMAP server over a REST API for syncing contacts and calendars.
It probably makes sense to give some more background here: We at audriga specialize in the field of data portability. In the context of a European initiative called NGI DAPSI we are working on extending groupware applications w.r.t. portability.
Currently, there is no API available to sync PIM data to or from Roundcube. However, that is exactly what would be necessary for a well-working migration to/from Roundcube. This is why our current focus is on PIM data and not on mail. Instead of using the good old CaxDAV standards we chose the upcoming JMAP standard. More specifically JMAP for Contacts and JMAP for Calendars. We believe that JMAP has the potential to replace CalDAV/CardDAV once it has finished standardization. Also, JMAP covers additional data, such as Signatures or Out-of-office-replies which might be useful to access by clients.
By adding a server-side JMAP API to Roundcube, JMAP-capable clients such as https://github.com/iNPUTmice/lttrs-android could be able to sync contact/calendar/settings data with Roundcube once support for this feature has been added.
We have already built a first PoC with which we are able to read and write contact data. However, we currently duplicated quite a lot of code of the index.php for this and we would love some insight into how to refine our first PoC. Maybe this could even be something that you could see incorporated into the RC core?
Yes, plugin is the way to go, but a lot of core changes might be needed.
If it was for replacing IMAP store with JMAP store for mail, I'd suggest using undocumented storage_driver option. This would require writing a storage handler class that inherits from rcube_storage. By default rcube_imap is doing this. Of course this will be only a start. The core is not really prepared to work with different engine. All data structures are imap-based and not really standardized.
Thanks for clarifying. I will keep that in mind. We want to focus with our first implementation on contact/calendar, but it is certainly good to know how support for JMAP for Mail could be added in the future.
If you're up to using JMAP server as a source of contacts or calendar, then it would be separate plugins, I suppose. They could use/require the common "jmap_storage" plugin you create. For contacts this should be reasonably easy. For calendar you'd have to integrate into an existing calendar plugin (I assume) which will require some changes in that plugin's code.
The plugin API is certainly something we would like to use. When implementing this as a Roundcube plugin we are currently unsure about:
- How to open up and authenticate against a REST endpoint for JMAP
clients to talk to. Maybe by registering a custom action and using a basic auth header somehow? I was unable to find plugins that add a REST API to Roundcube, which is supposed to be used from outside Roundcube.
- Which CaxDAV plugin to base our changes on. All the plugins we found
seem to implement the client side only.
Regards,
Joris
On 03.02.2021 08:40, Joris Baum wrote:
By adding a server-side JMAP API to Roundcube, JMAP-capable clients such as https://github.com/iNPUTmice/lttrs-android could be able to sync contact/calendar/settings data with Roundcube once support for this feature has been added.
We have already built a first PoC with which we are able to read and write contact data. However, we currently duplicated quite a lot of code of the index.php for this and we would love some insight into how to refine our first PoC. Maybe this could even be something that you could see incorporated into the RC core?
I understand why you'd like to make it a core feature, but this is not a mail client feature and I don't see it there.
The plugin API is certainly something we would like to use. When implementing this as a Roundcube plugin we are currently unsure about:
- How to open up and authenticate against a REST endpoint for JMAP
clients to talk to. Maybe by registering a custom action and using a basic auth header somehow? I was unable to find plugins that add a REST API to Roundcube, which is supposed to be used from outside Roundcube.
I'm afraid the plugin API is not prepared for this use-case. The first hook that is executed in a request is the 'startup' hook. You may try to use it to hijack the request to implement your service.
Plugins are loaded before the session is started, output classes loaded, etc. So, technicly you could put a code outside of the plugin class (but still in the plugin file) to make it executed as soon as possible, but this is really a hack.
Thanks for clarifying! Your feedback helped us quite a lot.
On 03.02.21 10:28, Aleksander Machniak wrote:
On 03.02.2021 08:40, Joris Baum wrote:
By adding a server-side JMAP API to Roundcube, JMAP-capable clients such as https://github.com/iNPUTmice/lttrs-android could be able to sync contact/calendar/settings data with Roundcube once support for this feature has been added.
We have already built a first PoC with which we are able to read and write contact data. However, we currently duplicated quite a lot of code of the index.php for this and we would love some insight into how to refine our first PoC. Maybe this could even be something that you could see incorporated into the RC core?
I understand why you'd like to make it a core feature, but this is not a mail client feature and I don't see it there.
The plugin API is certainly something we would like to use. When implementing this as a Roundcube plugin we are currently unsure about:
- How to open up and authenticate against a REST endpoint for JMAP
clients to talk to. Maybe by registering a custom action and using a basic auth header somehow? I was unable to find plugins that add a REST API to Roundcube, which is supposed to be used from outside Roundcube.
I'm afraid the plugin API is not prepared for this use-case. The first hook that is executed in a request is the 'startup' hook. You may try to use it to hijack the request to implement your service.
Plugins are loaded before the session is started, output classes loaded, etc. So, technicly you could put a code outside of the plugin class (but still in the plugin file) to make it executed as soon as possible, but this is really a hack.
Hello Joris,
your idea sounds cool, but my very personal opinion a Roundcube user (and I think also Aleksander is suggesting the same in between the lines) would be to implement a basic stand-alone JMAP server (handling only the Calendar/Contacts Stuff if it's the case you need to support) and then start implementing a JMAP client plugin in round cube that's referring to the JMAP server you're building.
I see the advantage of recycling Roundcube's tables for contacts but you're basically transforming a Client into a Server - RoundCube is just a WEB "version" of lttrs...
If you'd move in this direction count me as beta tester :-)
Andrea Brancatelli
Hello Joris
Although I'm late with this reply, I'd also like to give my votes to Andrea's suggestion. I think it might be the best option to make the JMAP server a stand-alone service because the full integration into Roundcube might be tricky. For this you could make use of the Roundcube framework which will give you direct and simplified access to Roundcube's datastore as well as handy utilities for authentication (-> via imap), session storage and caching. Long time ago we did something comparable (although less complex) for Kolab's Freebusy API (see https://git.kolab.org/diffusion/F/).
Serving contacts and basic setting from Roundcube should be easy using the Framework and if you like fancy challenges you might even build a JAMP <> IMAP bridge using Rouncube's IMAP client classes.
Good luck, we're looking forward to see your progress. And don't hesitate to ask back if you need more help.
~Thomas
On Wed, Feb 3, 2021 at 12:02 PM Andrea Brancatelli abrancatelli@schema31.it wrote:
Hello Joris,
your idea sounds cool, but my very personal opinion a Roundcube user (and I think also Aleksander is suggesting the same in between the lines) would be to implement a basic stand-alone JMAP server (handling only the Calendar/Contacts Stuff if it's the case you need to support) and then start implementing a JMAP client plugin in round cube that's referring to the JMAP server you're building.
I see the advantage of recycling Roundcube's tables for contacts but you're basically transforming a Client into a Server - RoundCube is just a WEB "version" of lttrs... If you'd move in this direction count me as beta tester :-)
*Andrea Brancatelli
Roundcube Development discussion mailing list dev@lists.roundcube.net http://lists.roundcube.net/mailman/listinfo/dev
Hi Thomas,
thanks for voting, clarifying and pointing us to the project. We will share it with you once we have made enough progress.
Regards,
Joris
On 28.02.21 18:13, Thomas Bruederli wrote:
Hello Joris
Although I'm late with this reply, I'd also like to give my votes to Andrea's suggestion. I think it might be the best option to make the JMAP server a stand-alone service because the full integration into Roundcube might be tricky. For this you could make use of the Roundcube framework which will give you direct and simplified access to Roundcube's datastore as well as handy utilities for authentication (-> via imap), session storage and caching. Long time ago we did something comparable (although less complex) for Kolab's Freebusy API (see https://git.kolab.org/diffusion/F/ https://git.kolab.org/diffusion/F/).
Serving contacts and basic setting from Roundcube should be easy using the Framework and if you like fancy challenges you might even build a JAMP <> IMAP bridge using Rouncube's IMAP client classes.
Good luck, we're looking forward to see your progress. And don't hesitate to ask back if you need more help.
~Thomas
On Wed, Feb 3, 2021 at 12:02 PM Andrea Brancatelli <abrancatelli@schema31.it mailto:abrancatelli@schema31.it> wrote:
Hello Joris, your idea sounds cool, but my very personal opinion a Roundcube user (and I think also Aleksander is suggesting the same in between the lines) would be to implement a basic stand-alone JMAP server (handling only the Calendar/Contacts Stuff if it's the case you need to support) and then start implementing a JMAP client plugin in round cube that's referring to the JMAP server you're building. I see the advantage of recycling Roundcube's tables for contacts but you're basically transforming a Client into a Server - RoundCube is just a WEB "version" of lttrs... If you'd move in this direction count me as beta tester :-) --- *Andrea Brancatelli * _______________________________________________ Roundcube Development discussion mailing list dev@lists.roundcube.net <mailto:dev@lists.roundcube.net> http://lists.roundcube.net/mailman/listinfo/dev <http://lists.roundcube.net/mailman/listinfo/dev>
Roundcube Development discussion mailing list dev@lists.roundcube.net http://lists.roundcube.net/mailman/listinfo/dev
-
Aleksander Machniak -
Andrea Brancatelli -
Joris Baum -
Thomas Bruederli