[vlc-devel] [PATCH 3/3] Add microdns services_advertisement submodule

[Alexandre Janniaux]

Hi,

On Mon, Sep 09, 2019 at 07:07:47PM +0300, Rémi Denis-Courmont wrote:
> Le maanantaina 9. syyskuuta 2019, 9.55.05 EEST Thomas Guillem a écrit :
> > On Sat, Sep 7, 2019, at 14:41, Rémi Denis-Courmont wrote:
> >  - The main sa module is loaded (Open() callback) and does nothing
> >  - vlc_sa_Start(protocol) is called on the main SA module, it return an
> > unique identifier, the called need to keep it in order to stop it in the
> > future.
> >
> > Problem: we leave the list handling to the module. Open() does nothing and
> > can't really know if it will fail, so no real module fallback.
>
> I still don't follow how you handle more than one advertisement protocol with
> that system. That seems to require that any module supports all protocols,
> which is missing the whole point of modules...

I agree with Rémi, the point of writing modules is especially to
avoid having things specific to an implementation/protocol/library
inside the core and force the code to be splitted into maintenable
parts.

I might be off-scope, but following this spirit, I might have
some suggestions, which join both ePirat's and Remi's comments:

Nothing prevent us from having service advertisement modules
not handling announce themselves but only the underlying service
lifetime, with the capability "service advertisement" and on the
other side having service announces modules with their own
capability like "bonjour service announce" or the one we don't
know yet.

That way:

+ Services announces modules are tighly coupled with service
advertisement modules, so if the service advertisement is not
there, the service announce module fails and another module can
takeover.

+ You don't launch the same service multiple time (which wouldn't
work anyway).

+ You don't need API endpoints in the core for announces, only
inline helpers. So there is less cost in the libvlc binary. The
dark counterpart is to define how announce object (if there is
one) are created, as inline helpers can't create custom objects.

+ You can have a microdns, avahi, bonjour service discovery and
still provide a common ground for all of them.

+ You can have services that support different kind of announces
as fallback.

+ If you run it with a sanitizer detecting invalid cast, you can
still avoid signature bugs.

+ You can provide a generic "announce" method through a generic
capability and module implementation, and each service
advertisement plugin can provide customization through variables
and configuration, because the announce has the caller object as
parent.

+ The lifetime of the announce is more concrete as it can be
represented by an announce object directly.

So it becomes simpler to generalize the design without breaking
anything later.

With this, you can still be in the situation where you try multiple
announce types (like mdns and generic), or trouble to define which
service announces what, which are different subject than how to
handle the announces.

Service advertisement looks hard, and having only one kind of
capability/module for it looks weird.

I hope this is clear and can provide some help and feed the
discussion,

Regards,
--
Alexandre Janniaux
Videolabs