Re: Service refactoring

[Ludovic Courtès]

"Thompson, David" <address@hidden> skribis:

> On Mon, Sep 21, 2015 at 12:00 PM, Ludovic Courtès <address@hidden> wrote:
>> Andy Wingo <address@hidden> skribis:
>>
>>> On Sun 20 Sep 2015 15:42, address@hidden (Ludovic Courtès) writes:
>>>
>>>> I’m quite happy with the result, but comments are welcome!  I’ll convert
>>>> some more services to see how it goes.
>>>
>>> Neat!  Sounds great.  One question: there are some services like colord
>>> or geoclue that don't need to be managed by DMD, but are just declared
>>> as services so that their users are created, there /var/foo directories
>>> are created, etc.  The can be started by D-Bus as needed.  Does the new
>>> design support services of this kind?
>>
>> Yes it does.
>>
>> ‘colord’ will “extend” the D-Bus service by giving it its package object
>> (thus its .service files), it will extend the activation service by
>> providing it #~(mkdir "/var/foo"), and it will extend the account
>> service by passing it its user accounts/groups.
>
> I'm picturing an enhanced 'nginx-service' that is able to accept site
> configuration files from other services (say, a MediaGoblin service)
> and it sounds like a great feature.

Yes, that’s the idea.

> Now, is the following scenario possible?: 'mediagoblin-service' can
> extend both 'apache-service' and 'nginx-service', and when the system
> configuration is realized, the web service the user has chosen is
> extended.

If it makes sense, there could be a single ‘web-service-type’ that both
Apache httpd and NGINX would implement.  The MediaGoblin service would
extend them by providing something like a vhost specification I suppose?

Now, perhaps we would need separate ‘httpd-service-type’ and
‘nginx-service-type’ if httpd and NGINX happen to be extensible in
different ways.  I don’t really know these tools, but it would be good
to see how we would do it.  WDYT?

Ludo’.