Hey,
i was exciting to read about the new ownCloud Infinite Scale: Tech Preview released! announced a few days ago.
Unfortunately i haven’t found any mentions on the future of the CalDAV (Calendars) and CardDAV (Contacts) integrations in ownCloud Infinite Scale so i would like to ask here on the future / plans of such an integration. Is there any documentation / reading available on this?
Very good question, this is also one of my major concerns.
CalDAV (Calendars) and CardDAV (Contacts) are absolute killer features for me. OK, the apps I could drop, but not the services behind. Without them, the new and shiny ownCloud Infinite Scale becomes useless.
Full disclosure: lead architect of OCIS here.
OCIS is currently targeting the file sync and share functionality only. The idea is to leverage the microservice architecture to scale individual services as needed. In the beginning, we cannot bring back all features of oc10.
Personally, I am looking into kopano as a mail and calendar solution. We already embed konnectd as the OpenID Connect identity provider and it might make more sense to work an integration the rewriting the calendar and contacts.
There are always other ways forward, however.
Aside from integrating better with kopano we could look into roadrunner, a go implementation of pho from that allows handing off requests from go to php. It would be possible to implement the oc10 php interfaces and run existing oc apps in an independent sandbox as a service.
But I don’t see that happening until we, as in ownCloud GmbH, have a solid product feature set for an enterprise file sync and share solution. Do one thing and do it well.
I am super happy the Klaas is back on board as he knows a lot about the desktop client and the sync protocol. Which, in the end is more important than the technology stack being used.
That being said you may have noticed the lack of new features in oc10 over the past year. We were focusing on OCIS, but are investing more people in oc 10 as well. It will get an update to php 8 and we are investigating ways of running OCIS or at least some services along oc10. The OpenID IdP for example will become more important as it allows properly authenticating clients.
In the end it might be a longer transition phase. Please let us know your thoughts and concerns.
Again, personally I am looking into kopano for calendar and contacts as it allows using active sync to access it from any Android device without installing an additional app.
If anyone wants to dig into golang and roadrunner ping me in https://talk.owncloud.com. Happy to help get started! See https://roadrunner.dev/
So… 2021 will be an exciting year for ownCloud!
I would also underline that calendar and contacts are “killer features” of most current OC installations around. But I would think of it based on functionality, not the technology behind. If there are good go solutions for caldav/carddav integration (kopano?) around it is better to integrate them than to build new applications from scratch.
I started with OC before the segregation OC/NC and kept to OC since then. I think the business strategy of concentrating on sharing functionality plus a scalable technology (go + microservice arch) to get a solid product will be - in the middle run - better than the “all in one solution” strategy of NC. But nevertheless even OCIS needs to show that its open for additional functionality and attractive for new developers.
It would be good if we have at least calendar and contacts integrated when ocis is ready for production. I personally would also love if onlyoffice could be integrated from the start, but all other functionality we see in OC 10.5/6 can come later. The number of go developers is currently smaller than the number of people who are familiar with PHP. It will take some time until people start with a new language and have their toolchains ready for go development.
Hey @butonic,
thank you so much for this detailed answer.
For me calendar and contacts are the “killer features” of ownCloud as well (besides the main file share / sync functionality, currently i’m not in the need of any new feature) and it would be a great loss for me to not have them anymore.
What worries me the most is that i have read somewhere (i think at some github issue) that ownCloud 10 won’t live long anymore. I hope i can use ownCloud 10 long enough until OCIS is ready / having the calendar and contacts functionality.
In the light of the discussion here I have transitioned to NextCloud. Contacts and calendars are essential to me and any doubt that they might not be included in OCIS is the straw that breaks the camel’s back.
Hi tom42, I can assure you that ownCloud 10.x (ownCloud Classic) will be with us for quite a while. In any case at least for another 3 years. As Botonic said, we are making ownCloud 10 fit for the future, for example with PHP 8 support. ownCloud 10 is currently the reliable product that the community and our customers trust in, and that will remain so for the time being.
Hey,
this is great to hear. Thank you very much for this additional insight and information about the future of ownCloud 10.
Can someone from OC give us an update about the current status (with OCIS 2.x being live now) of this “feature” discussion. While I still support the overall strategy of focusing on file share and scalability with OCIS: I would be interested in some info if there are other solutions recomemnded to be included into OCIS stack to keep the current CALDAV/CARDDAV functionality when migrating from OC to OCIS…
Are there any examples for caldav/carddav integration into OCIS or docs ?
i think i have read about a recommendation somewhere in the beginning of OCIS…
its a unclear memory: something that also was used for user login/management…
as I just stumbled again over this topic in search results:
the newest info as fare as i found is in
Just an update from my side: I successfully migrated to OCIS now, including CalDAV/CardDAV. OC classic will be switched off after christmas. The setup consists of:
Result: its fast, its stable, the ressource footprint is low and its “feature complete” for my current use cases.