tillmo

We have three proposals for the way of supporting git repositories: #Way 1: Gitlab/Github plus webhooks The backend communicates with any Gitlab instance and/or Github via webhooks. We don't do anything anymore about file hosting, editing and so on. We only serve as a CI-tool. Pros:

• We concentrate on our expertise and leave the file handling to the guys that know it.
• Users don't have to wait for file editing features on Ontohub because we don't develop them.
• We expect that implementing this new ontohub is much easier and finished earlier.

Cons:

tillmo

We have decided to re-implement Ontohub from scratch, because

• even if there is some decoupling into services, the core service (written in Ruby on Rails 3) is still too monolithic and therefore unmanageably complex. It shall be therefore decoupled into a backend (in Ruby on Rails 5) and a frontend (in ember.js).
• this further decoupling of services follows the OOR architecture
• we would need to migrate from Ruby on Rails 3 (which will be no longer maintained) to Ruby on Rails 5 in several steps, which could be even more costly than a re-implementation.
• we could not get along with many problems in using sidekiq as a background service. We hope that RabbitMQ, a true service broker, will be better here. Moreover, servers providing Hets as a service can be registered more easily
• new program