Feature Wiki
Tabs
Introduce Activities
Page Overview
[Hide]1 Aim of Project
The aim of this project should sound familiar, as we already attempted something similar under the moniker Introduction of Service Discovery / Internal API alignment. This project is a new approach to a similar aim, with a slightly changed wording. At the time of writing, ILIAS has no discernible layer where we can find "Activites" with objects and facilities in the system. The project should improve in that regard, for various benefits. What do we mean with this sentence?
Initially, ILIAS was developed as a simple "CRUD"-style application, as witnessed by the create/read/update/delete-methods of ilObject. This simplistic view was abandoned long ago, and ILIAS got components known as "Services" that offer functionality internally to other components. Nowadays many of these services offer decent and well documented APIs to other components and we are on a good route to improve in that area.
But another area, where we would expect "APIs" have not been adressed until now. This is the area, that the Introduction of Service Discovery / Internal API alignment-proposal aimed to adress. While the internal "Services" provide APIs to other components, there are Activities within the system that happen on the domain layer of our application and that cannot yet be referenced and used explicitly. An Activity is understood to be a way in which a user wants to use our system. E.g.: Create a Course. Add Members to a Group. Make a Test available.
These examples, superficially, might look as if they could be mapped onto according calls on existing objects, such as ilObjCourse::create, ilParticipants::addMember or ilObjTest::setOnline. But in reality this is not the case. When users say they want to create a course, they do no only mean to programmatically "Create a ilObjCourse"-object. The object needs to be put in the Repository somewhere. Permissions need to be checked. Same for "Add Members to a Group". This is what the "Domain" of our software is, in difference to the programming that we use to implement that domain. Currently, the code of our software does not allow to encode Activities on the domain. Instead, they are encoded in some GUI that controls these activities or they are implicitly implemented via the concrete control flow that some request of a user takes. This is also the thing, that the Introduction of Service Discovery / Internal API alignment aimed to change.
Despite the slightly changed wording ("Activity" instead of "API"), the benefits are the same as they have been. Activities will
- offer a way to present a domain level API to other developers, webservices and end users in a machine-readable way.
- offer documentation in the ILIAS GUI for end users to take advantage of the available services e.g. in webservice integrations or workflow definitions.
- move APIs as back into the maintenances of the proper maintainers in a consumer-agnostic way.
This will improve our development processes as well and allow for new possibilities:
- Maintainers have better insight into changes to activities. Cross-communications with webservice-maintainers about changes are not required. A maintainer will be responsible for a domain level API to their component being available and properly working.
- New domain level API methods that allow interaction with the core will be in the control and responsibility of the affected components maintainer, making coordination and eventual subcontracting with a webservice maintainer unnecessary.
- Newly introduced consumers may take advantage of existing APIs without a duplicate effort to recreating existing means for their specific purposes.
2 Involved Maintainers and Stakeholders
- will be usable by every maintainer with a user facing component.
- Webservices such as SOAP can be switched to use Activities
3 Timeline
ILIAS 10 |
|
ILIAS 11 |
|
4 Related Feature Requests and Status
Feature Request | Suggested by | Funding | Planned Release | Status |
---|---|---|---|---|
… | ||||
… | ||||
… | ||||
… |
5 Further Results
- …
6 Additional Information
…
7 General Discussion
Please discuss specific questions of feature requests on the related feature wiki pages. This discussion section is only for a general discussion of the project and its realisation.
JourFixe, ILIAS [jourfixe], 27 NOV 2023 : Richard presented his plans to realise an activities layer. For ILIAS 10 he plans to complete the concept and for 11 to implement a first version.
This big project „Introduce Activities“ picks up an important puzzle piece in code modularization, that’s lingering in the backlog since many years. The Technical Board agrees not only on the matter itself being of importance, but also on the state of ILIAS right now to move forward with this initiative and approves it as a „Big Project“ for ILIAS.
It is very important for the modularisation of ILIAS and thus for ILIAS as an Adaptable Learning Environment as stated in the strategy → see here .
The Technical Board understands the worries of the developer community to being overwhelmed by many structural changes in the ILIAS core and our approval here is also a signal we do not just push any of the many good ideas forward, but pick those with the greatest value in perspective.
The TB wishes for a workshop at the Development Conference, addressing all the factors and also open the discussion with the developers, who are all involved in this project.
We thank Richard Klees for bringing this to our attention so early. Historically, this was interesting for especially for the WebServices and other Services/Interfaces. With the new iteration, we see a potential to also manage cross-component on domain level operation in general with an approach structured like the one presented. We see homogenising the language used across services and components as an important factor for the longterm success of ILIAS.
We kindly ask Richard Klees to keep the community involved, but also to make sure that significant parts of the community can follow and are not lost to the process.
Statement UX/UI/A11y-Experts, 6 DEC 2023
A modern and stable code architecture is necessary to enable and tackle improvements in UI/UX/accessibility. It seems to us that this project contributes to code quality and therefore indirectly and in the future helps to improve the accessibility, UI and UX of ILIAS. We therefore welcome this Big Development Project and would give this a prioritization level 3.
11 DEC 2023: For the product manager, the proposal is an exciting and ambitious proposal to improve interaction with ILIAS and drive its modularisation forward. As already mentioned by the TB, all ILIAS developers should be able to familiarise themselves with the concept and its implications at an early stage. The DevConf in March or September would be a good opportunity to present and discuss the concept in detail.
…
Last edited: 11. Dec 2023, 10:30, Kunkel, Matthias [mkunkel]