[dev] Upstreaming maintaina fork soon?

[Ralf Lang]

Hello,

let's discuss and decide if you want to integrate most of the 
maintaina-com fork into the master branch (soon) or what are the 
blockers or if it is generally not wanted.

 From my perspective, the cross cutting work has been finished and if 
this going upstream, delivering additional features one at a time 
through individual pull requests would work. If you decide you don't 
want that, then I better learn that now than later.


The forked code base is php 7.4+ and about as well/badly tested on PHP 
8.x as horde's master branch.

I took a lot of backward compatibility measures.

Whatever custom H5 compatible apps or libraries are out there, they will 
most likely work with this new code with little or no work. Also, most 
of the new code is either opt-in, adopt-one-piece-at-a-time or it 
provides wrappers with the old interfaces.

Development was driven mostly by my own or customer needs and interests 
and I did not especially take care in keeping all the changes separated. 
That should change for followup projects.

Initially I kept all things compatible with git-tools and pear based 
installs. I'd like to drop that at some point.


Main Features/Changes:

*Composer instead of pear, Release Tools:*

All horde libs and apps are now composer 2.0 packaged.
All dependencies have been replaced by things available on packagist or 
in the repo which feeds horde

.horde.yml format has been enhanced to support require-dev, suggests, 
custom autoloading, custom vendor binary list etc. Most settings should 
not be necessary for most packages.

horde-components has been ported into in a namespaced, PSR-4 compatible 
codebase and some git features have been ported from git-tools. Also, 
release command has more customisation options.

A composer installer library sets up all the horde-specific stuff like 
the horde.local.php file, registry snippets, autoloader related stuff. 
Parts of that could be thrown out sacrificing some assumptions needed by 
the git-tools install.

All unit tests now run in phpunit 9

Some pearish assumptions on require_once file locations have been turned 
into if clauses. "If class is not autoloadable, require..." These could 
be dropped at a later stage.

Publishing to packagist rather than a custom satis server is possible at 
any time.

*CalDAV and CardDAV**
*

An upgrade to the most recent sabre/dav code was necessary.
The upgrade would allow implementing many more improvements like proper 
ACLs but I did not invest time yet.

Some work went into turba and kronolith to improve caldav/carddav sync 
experience.

- Reducing invitation spam in multiple scenarios
- LDAP or other backend changing contents without Horde_History knowing
- Partial support for UTF8 icalendar content
- Some support for vcard 4.0 on the library level.
- Partial support for handling carddav attributes the backend doesn't 
care for

This affects horde/dav, horde/icalendar, horde/itip, horde/core, 
horde/turba, horde/kronolith, horde/nag

*Horde Injector**DI Container
*

Injector has been ported to PSR-4 autoloadable namespaced code.
A set of PSR-0 autoloadable wrappers or derived classes exists to make 
it a drop-in replacement
PSR-11 interfaces were added but the original getInstance, setInstance 
etc calls are still available
Limited work to support scalar and array type hints

*Horde_Rdo ORM
*

I read up a lot on old presentations Chuck did and his remarks in the 
wiki. I use Horde_Rdo a lot in custom code, but I decided a straight 
forward port to namespaces would be bad.

The the unnamespaced classes in lib/ are literally the 5 year old code 
from Horde 5.

The namespaced code in src/ contains a feature compatible wrapper on top 
of a more loosely coupled code base. Interfaces instead of base classes, 
a default implementation instead of an abstract class,

not exposing all those magic, typehint-unfriendly variables, better 
support for wrapping the data objects into lists of business objects...

*Horde Controller Framework and Horde_Http
*

My custom projects used the Horde Controller Framework a lot so 
originally I just ported it to make it work with composer. I also tried 
to add optional basic authentication but this proved to be a messy approach.

More recently, I decided to start over.

horde/http contains both the original unnamespaced H5 Horde_Http_Client, 
Request, Response etc as of git master and a namespaced, incompatible 
alternative.

The new code implements all the HTTP PSRs, PSR-7 message, PSR-17 message 
factories, PSR-18 HTTP Client. I did not refactor any of horde's 
horde/service_* libraries to actually use the new code but we should be 
able to do this one at a time without the need to do all.

The technology specific part moved from the request/response objects to 
the Client implementation. A wrapper extends the PSR-18 clients (fopen, 
curl, pecl/http) with some niceties from the original horde_http_client

I decided against improving horde/controller apart from 
wrappers/converters between PSR-7 Request/Response and Horde_Controller 
Request/Response. This supports existing codebase. Official Horde mostly 
has nag and content, but I have some more use cases I cannot port overnight.

For new code, horde/http_server implements PSR-15 middleware and request 
handlers.

Based on this, new code in horde/core completely replaces the 
Horde_Core_Controller* things. We still read the routes.php file in each 
app and we still have all that magic around the /app/ folder and the 
special naming conventions in there to support existing code.

The new concept lets you define stacks of middlewares instead of just a 
controller (which still works),

keeping purposes like logging, authentication for API scenarios, 
gzipping etc out of the runner framework or the controller handling the 
request. Horde_Controller did have pre and post filters but it was badly 
documented and almost no use cases existed, so I followed the industry 
standard instead.

I have implemented middlewares which handle horde session authentication 
and redirect to login on failure just like H5 controller framework 
behaves. This is the default stack unless another stack is hinted in the 
routes.php file. I have also drafted middlewares for isAdmin and 
hasPermission. The current implementation still does the whole appInit 
routine with all its secret setup magic.

You should be able to throw away horde/http_server and possibly also 
most of horde/http and just use some existing implementation, if you 
like to.

*Horde/autoloader*

Only very limited work went in here. It's still needed for some code 
paths but new code does not rely on it.


*horde/ingo*

Some of the refactored code between Horde 5.2 and horde master was 
touched because it did not work in production.

*Other*

- Support for composer installable themes was added.
- horde base now is on the same level as applications. Thus, RPC 
endpoint has moved from /rpc/ to /horde/rpc/ but code for backward 
compatibility exists.
- New code follows PSR-12. This conflicts with Horde/Pear's convention 
of underscoring private variables.



-- 

Ralf Lang
Linux Consultant / Developer
Tel.: +49-170-6381563
Mail: lang at b1-systems.de
B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537