On 1/21/2015 7:19 PM, post-sysv wrote:
I'm not sure what effective and worthwhile ways there are to express
service *relationships*,
however, or what that would exactly entail. I think service conflicts
and service bindings might
be flimsy to express without a formal system, though I don't think
it's anything that pre-start
conditional checks and finish checks can't emulate, perhaps less
elegantly?
This brings to mind the discussion from Jan. 8 about "./provides", where
a defining a daemon implies:
* the service that it actually provides (SMTP, IMAP, database, etc.);
think of it as the "doing", the piece that performs work
* a data transport (pipe, file, fifo, socket, IPv4, etc.); think of it
as how you connect to it
* a protocol (HTTP, etc.); think of it as a grammar for conversing with
the service, with vertical/specific applications like MySQL having their
own grammars, i.e. MySQL-3, MySQL-4, MySQL-5, etc. for each generation
that the grammar changes.
I'm sure there are other bits and pieces missing. With regard to
relationships, if you had a mapping of these, it would be a start
towards a set of formal (although incomplete) definitions. From that
you could say "I need a database that speaks MySQL-4 over a file socket"
and you could, in theory, have a separate program bring up MySQL 4.01
over a file socket when needed.
But do we really need this?
