search

sabre-io / Baikal

Baïkal is a Calendar+Contacts server
https://sabre.io/baikal/
GNU General Public License v3.0
2.49k stars 286 forks source link

Maintenance status of this project #831

Closed tchapi closed 4 years ago

tchapi commented 5 years ago

Hi all,

I would like to know the current status of this project ... maintainance-wise.

I see that @evert has stopped working on the project since 2017 more or less, and that @ByteHamster has made a recent release.. @ByteHamster are you the new lead maintainer ?

I use this project myself (thanks to all the devs that created it and made it a quite powerful and practical Caldav/Carddav server), and would like to contribute to it, but I'm wondering if I should completely fork and fix things on my side, or if it's worth creating PR's on this repo and trying to stick to a kind of "official" roadmap.

I'm looking at sanitizing the code base, rewriting the back office (Some progress has been already made but abandonned on a modern PHP framework), fixing the configuration parsing, etc ...

Thanks a lot ! BR

ByteHamster commented 5 years ago

I am currently maintaining the project, yes. My personal goal with Baikal is to keep it alive but not spend too much time on it. If you want to spend more time and rewrite stuff, I would be happy to review and merge pull requests. I would prefer incremental changes because they are easier to review.

Also, have a look at #568 where big parts were rewritten and then the used framework (Silex) became unmaintained. Might be easier to start from that PR.

Please make sure that there is an automatic upgrade path if you change the config files.

tchapi commented 5 years ago

Hi and thanks for your quick answer.

I have looked at #568 and that would clearly give some inspiration but as you said Silex is unmaintained, and I would definitely choose something more robust (and that has a strong community, i.e. Laravel or Symfony for instance).

As for the config, it's kind of a real mess right now with the custom parsing, so I would aim at something much more standard (maybe dotenv that would play well with a dockerized installation for instance) but understood for the upgrade path (this is going to be the hardest part IMHO).

Anyway these will be differents projects altogether

Are you the sole contributor / maintainer / PR tester these days or are there some other folks helping out already ?

BR

evert commented 5 years ago

A new config format would be awesome! I agree that the silex branch is probably better to leave behind, but it might still be a good place to look for inspiration. Migrating to a new configuration format was a little tricky

tchapi commented 5 years ago

Sure it looks tricky, but without a correct configuration, the project will likely not last longer ...

Now I'm not saying that I can dedicate weeks to this ;), but in my quest to hosting my personal open-source services such as a calendar and contacts (amongst other), Baikal was still one of the best and friendly alternatives out there, and the least I can do is to give some time back to this project. I think there is space for a nice PHP 7 "PSR compliant" Caldav/Carddav server.

I'll try to dive into the code in the coming weeks, see how I can contribute to the configuration system first.

tchapi commented 5 years ago

PS : on this configuration topic, do you agree that all the settings (standard and 'system') should not be editable in the back office, but rather be dependant on the deployment, i.e. should live strictly separated from code, and possibly be linked to the application's environment (dev, local, staging, production, etc ...) ?

ByteHamster commented 5 years ago

Are you the sole contributor / maintainer / PR tester these days or are there some other folks helping out already ?

Evert is still there for advice but mostly does not commit/test anymore.

Anyway these will be differents projects altogether

Do you know Katana? If everything needs to be rewritten anyway, we might consider switching to it. Katana is Javascript based and was designed to work with every dav server, not just sabre/dav. https://github.com/sabre-io/katana

The sabre-io maintainers don't seem to have a strong preference about what project to continue. The only important thing is to always provide an upgrade path from Baikal and continue the rewrite under the name Baikal.

tchapi commented 5 years ago

Oh — I didn't know Katana at all. I will check it out more in depth. But as I understand it's quite old (4/5 years old approx. ?). My guess is that Baïkal is more up to date (with sabre/dav 4.0.1) and field-tested and that updating Katana will likely be as difficult anyway.

Moreover, for my personal use (and the use of people I know that use a self-hosted caldav/carddav server), I don't see a real benefit of having a full-fledged js admin interface. I'm more interested in a robust, proven, easily installable / upgradable server, compliant with standards, using recent tech. But I guess that depends.

The email templates from Katana seem nice though :)

evert commented 5 years ago

PS : on this configuration topic, do you agree that all the settings (standard and 'system') should not be editable in the back office, but rather be dependant on the deployment, i.e. should live strictly separated from code, and possibly be linked to the application's environment (dev, local, staging, production, etc ...) ?

I don't 100% agree with this, because one of the nice features of Baikal is that there's an interactive installer. The ability to install the system and choosing the the Database configuration is imho a nice feature.

It's not the worst thing if it goes away, but it would be a bit of a shame. Honestly the first and best first step is to simply move the current config to either a dotenv-style file or a JSON file. It would be a great step forward.

tchapi commented 5 years ago

I understand your point, let me explain my view more precisely :

What I mean is that these settings in particular should not be changed dynamically via a web UI, and as they require some work on the server, it's far easier to put them in an immutable .env file anyway. They belong to the environment.

The remaining settings (cal enabled, webdav digest, ...), why not.

Now, your point on an interactive installer is a different matter.

Since developers are required to composer install in the project directory, I would recommend putting these remaining settings in a YAML file (parsing and writing is easy), and use a tool like Incenteev's parameter handler to automatically ask them in the process. And then yes, we could edit them in the web UI.

For the other environment dependant values (db params, etc), dotenv is really a good choice but .env files are not meant to be programmatically changed (no correct library I know allows to write it, for a good reason), so we would be left with having to rewrite a parser / writer, which defeats the purpose (and would be dangerous).

Moreover, I'm convinced that if you want Baïkal to be easily deployable, containerizable, upgradable, etc, and be able to integrate it in standard deployment tools, it needs to embrace more standard patterns for its configuration.

So my proposal would be dotenv + a YAML file. If you think this is not where Baïkal should go, no problem, I'll fork and work on my version.

PS : maybe this kind of discussions needs to happen outside of Github issues ? I don't know, happy to discuss it elsewhere if needed.

evert commented 5 years ago

In the "system settings", you can't change the DB settings (be it SQLite or MySQL) without previously having created a new database and having run the fixtures (in Core/Resources/Db/...) separately, via your cli or DB explorer of choice (I'm not even talking about the security issue of having the DB password in the interface).

A purpose of this is probably less being able to install from scratch, but moreso if SQL settings change due to for example a change of host.

For the Auth realm, changing it in the web UI will render your password completely useless and you won't be able to login again (and all your users' passwords will be unusable too, and since you won't have access to the admin UI anymore, well, you won't be able to reset them)

Agree here, this is not great. We should really switch to Basic + bcrypt hashes anyway, so if we lose the ability to change this imho this is ok.

Changing the cal / dav / card paths will require that you effectively move the files and/or create new endpoints in your server and possibly your webserver (Apache, Nginx, ...)

Agreed, this doesn't need to be changed by users.

The PROJECT_TIMEZONE should not be a configuration — it should rely on the PHP timezone of the server since it's what it sets in the end in the framework

Disagree with this one. Would prefer to keep this ability.

Since developers are required to composer install in the project directory, I would recommend putting these remaining settings in a YAML file (parsing and writing is easy), and use a tool like Incenteev's parameter handler to automatically ask them in the process. And then yes, we could edit them in the web UI.

This is actually not correct. When users install the default baikal distribution they don't run composer install. This is only true for dev builds or github clones. There's also many people that run Baikal on appliances or other packages that don't even touch the cli.

So my proposal would be dotenv + a YAML file. If you think this is not where Baïkal should go, no problem, I'll fork and work on my version.

I completely understand this. I see where you are coming from, and it would be very nice if Baikal could be configured this way as well, but I don't feel good about losing all these existing features and leaves folks out in the cold. Perhaps the perfect compromise is a combination of both. Perhaps (most of) the configuration panel can be disabled if settings were provided via the environment.

But if you feel that this is too much for you to take on, a fork might be the best route.

tchapi commented 4 years ago

Hello @evert, @ByteHamster,

So I've followed your inputs and implemented symfony/yaml and YAML configuration files, so as to test and get a bit more acustomed to the code base.

There are two configuration files : config.yaml and system.yaml, to stick to the actual behavior. They reside in the config directory (This is the Symfony standard structure). They both have a .dist counterpart for developers to duplicate, but they are correctly created via the install wizard.

It basically works well, the admin interface is no different from before, except from some removals (as per what you agreed on). I haven't tested everything yet — the upgrade path is a pain though, there still might be some bugs on this side (but it's a kind of an "unknown unknown" for me).

But the real problem lies elsewhere. This configuration overhaul could be the first step of small incremental improvements to the projet, but unfortunately, the whole structure of the code is too non-standard to be salvaged (IMHO).

The pseudo "Flake" / "Formal" framework is definitely not on par, relies on globals everywhere, does not support any kind of DI, and has so many things hardcoded that it's litteraly impossible to make a small change without breaking everything. The code + repo structure itself does not comply to any common pattern.

So even with a correct configuration, there is still a wall before the code can reach some of today's standard.

At this point, I'm considering that it's easier to start from scratch and create an admin interface over sabre/dav in Symfony 4. This is a pity that Silex is not maintained since it would have been a lot easier to continue the work already done in this branch.

Anyway, if you want to have a look, here is my branch : https://github.com/tchapi/Baikal/tree/rework/configuration and the relevant PR I made : https://github.com/sabre-io/Baikal/pull/835 (but I would consider this relatively quirky since I definitely don't trust the underlying framework as I said)

Significant modifications / removals :