bug#27155: [PATCH 0/2] Support service extensions on the "final" service values

[Ludovic Courtès]

Hi Ricardo,

Ricardo Wurmus <address@hidden> skribis:

> I think it is useful to have the ability to add rewriters at the end of
> service composition.  In my opinion it is always good to have an escape
> hatch, and this seems to fit the bill.  But I agree that it is not
> an elegant solution, and I wouldn’t want to advocate using it.

Right.  As discussed on IRC, one problem is ordering: if there are
several users of this features for a given service, you can’t really
tell what’s going to happen, unless the modifications happen to be
commutable.

> As to your second idea: it seems tedious for service writers to have to
> anticipate the ways in which services could be extended (here given by
> providing extension points).

Boilerplate aside, I’m not sure it would be this tedious.

> Would it make more sense to allow *extensions* to specify how they
> should be applied rather than letting services define extension points?
> This would shift the burden away from services to service extensions.
> Extensions would still need to provide a way of extending the parent
> service, but this could be optional.

What would it look like?

It seems to me there are two options: either service type specify how
they can be extended, or they expose their raw values letting any
extension alter it (the patch I sent).

Thanks for your feedback!

Ludo’.