We use simple inheritance for all of our classes. Since PHP doesn't support multiple inheritance, we end up with a proliferation of sub-classes. This affects Services in particular, where we end up with separate implementations of SSL for Apache and Nginx, without being able to share code between them.

PHP 5.4 introduced traits which, along with interfaces could provide more flexible and easily extensible object models.


anarcat’s picture

See also #955018: ability to save new arbitrary data to a context from outside the service. I also remember talking with someone in London about having "subservices" to resolve that issue, but I can't find the issue right now.

ergonlogic’s picture

Starting around here we discuss some of the challenges with the current model.

anarcat’s picture

basically, that discussion revolves around how it's impossible or very diffcult (i couldn't figure out how) to operate on multiple servers (which is usually done through the services modules) from outside services. to implement the subdir support, I had to hack into the Apache service directly, as opposed to be able to hook into it from outside.

it may not be a limitation of the code as much as problems with the documentation, but I couldn't figure it out in an afternoon.

Also, I had a lenghty conversation with @tizzo about Drush Fetcher. Basically, tizzo asked me if we were duplicating our efforts with Provision, and I answered that he was just laying the foundation for Aegir 4. ;) Fetcher is basically a clean room reimplementation of provision with closures, namespaces, autoloading and all sorts of interesting modularity. They have a similar object model than us, except it's much cleaner and understandable, as it is based on on Pimple as opposed to be a native, buggy and incomplete implementation like we do.

I think this would be a great basis for the rewrite of the backend I have been looking forward for years. A couple of things are missing from Fetcher, I believe:

* multi-server / cluster support - it operates only on a local environment, and is strongly oriented in the "creating a local dev env" approach
* the commandline interface is similarly limited to operate on an existing list of sites more than being completely autonomous
* migration from our current storage mechanism
* task / queuing system - there are some ideas about "jobs" and tasks right now, but those are fairly limited (see also #2049543: Refactor our queue using the Drupal Queue API)
* no nginx support
* no backward compatibility with all our contrib module fauna - although we could have backward compatibility shims
* lacks our "server" abstraction
* no DNS support
* limited or no multi-site support

Also, fetch basically re-implements drush make (in a way), so this conflicts with our current approach of reusing existing tools. We could, however, implement a fetcher subclass that would simply talk with drush make...

We also discussed how drush limited us severely - the code is getting old, and drush is used. I even proposed we start considering rewriting the drush core to be a simpler and better defined API (#smallcore anyone?), which was an interesting discussion, but quite an undertaking.

I do feel that a lot of those concepts belong to drush, and that was the basic idea behind our d() and class structure - that they would eventually get merged back into drush.

Anyways, we need to continue the conversation with @tizzo and the proviso people about this, for sure.

Again, I think we should seriously reconsider rewriting our backend with this, if we are to continue with PHP at all here. :)

ergonlogic’s picture

The approach taken by drush_fetcher looks promising.

Note that I just posted an example of implementing a minimalist service to save data into a site context: #2103173: Provide an example of saving data to a site context. It currently comes to ~250 lines of code. This strikes me as a lot.

helmo’s picture

Issue summary: View changes
Status: Active » Postponed

@ergonlogic's https://www.drupal.org/project/aegir_objects is a step in the right direction for this issue.

Setting the status to postponed as it's not actionable right now.