Proposal: Split Front End and Provider

[dylanmorroll]

I was wondering what people's thoughts would be on splitting the front and provider into individual projects would be?

I'm sure many of you have seen this image:
https://www.davx5.com/fileadmin/user_upload/faq/how_davx5_works.svg

I'm not too sure why Tasks went with their own provider instead of using the OpenTasks provider like aCalendar does, but perhaps decoupling the front end from the back end of OpenTasks would allow for more flexibility and improve the adoption of this setup? If the provider was a separate application it could serve as a single source of integration that many different task apps (including the front end of this project) could integrate with.

Just some food for thought!

[dmfs]

I see several reasons why, as a task app developer, you'd still want to develop your own back end.

• you don't want depend on other projects to adopt/merge changes you need to support new features in your front end
• you want to be sure that the back end version matches your front end version. If that's not guaranteed (because both are maintained, published and distributed separately at different pace) you may have a lot of additional work to check the back end version and disable/enable features accordingly.
• your task back end is a critical component for your product and "out sourcing" it is a big risk. For aCalendar this is just an additional feature they can just EOL if OpenTasks is discontinued. It's not so easy if your core functionality depends on a 3rd party project.
• for the end user the user experience would suffer when they have to install two separate apps to get any functionality at all

Actually, a few years ago, the provider was a separate project (though not a separate app yet): https://github.com/dmfs/opentasks-provider
The goal was to make it the equivalent of the android calendar provider and to contribute both provider and UI as two separate apps to the AOSP. However, there was little to no interest on their end so I gave up on this goal and integrated the provider as a separate module into this repo, which makes it way easier to maintain.

Fow now the goal is to make OpenTasks extensible and to make it easy to add new functionality with some sort of plugin mechanism. That's already in the works and, as a matter of fact, some of its own functionality will be implemented as plug-ins. 3rd party apps will be able to provide plug-ins too of course.

[dylanmorroll]

Thanks for the response, very informative. I like the idea of it being equivalent to the android calendar project, it's a shame that never took off!

Is there any Open Standard for a task provider? Then that would provide some stability to the back end and increase reliability for any front end apps that wanted to use it.

[dmfs]

I'm not aware of any open standard for a task provider. We're trying to be compliant with other open calendaring standards like iCalendar/VTODO though.
Stability is probably not the biggest issue. Our back end is quite stable. In particular, I can't remember any breaking changes in the provider contract. It still lacks many important features though.

[dylanmorroll]

That makes sense, well thanks for all the info! Good luck with it all and hopefully if I ever get some free time I'll be able to help out a bit :)

Will close this issue now, appreciate the feedback!