One common issue is that for some apps there is one app implementing some APIs and another one using it. This creates inter-app dependencies which so far was frowned upon.
For this reason, some app's code and interfaces has been moved into core to make sure other apps can use it.
Let's take the existing activity feature as an example:
- core contains an ActivityManager (Activity\IManager) that apps can use to publish activities (Backend)
- the owncloud/activity app connects to it to be able to display activities (Frontend)
- other apps (ex: files, calendar, etc) would connect to the ActivityManager to publish activities like "file was renamed", "calendar event was created", etc (publishers/clients)
What if in the future someone would implement an app that implements another service that doesn't exist in core ? That app would need to submit a PR to core with the necessary code. This is a no go for complex app development.
To solve this, here is an idea: let apps be either a provider or a consumer of services.
A service is simply a class with a namespace and an interface, defined in info.xml.
If we model the activity feature after this there would be three different apps:
- activity-service: an app that only provides the backend for publishing activities. Its info.xml would declare that it provides a service called "IActivityManager"
- activity-frontend: an app that displays a list of activities in a full page. Its info.xml would declare that it requires a service called "IActivityManager". The requirement here would be a hard-requirement, so the app cannot be enabled if there is no other app providing "IActvitiyManager"
- files: the files app would declare in its info.xml that it optionally requires a service called "IActivityManager". Optional means that if no app provides this service, the app can still be enabled but will skip publishing activities
- calendar: same as files
Now with this model, maybe someone writes another app that implements "IActivityManager" better. That app could also declare that it provides this service. Now if two apps are enabled providing the same service, either it should be denied or the clients need to be able to select one of them. This case might be rare though.
Also, nothing speaks against having one app implement both the service and consume it at the same time. But having the service "public" as part of info.xml makes it possible for other apps to use it too.
If we go that route, a lot of core code could be moved to apps eventually and have core be lighter.