[MapProxy-dev] PSC Voting required - Plugin infrastructure

[Johannes Weskamm]

+1 from my side for having a plugin architecture to support external
services or sources.


Greetings,

Johannes


Am 22.03.22 um 13:45 schrieb Johannes Weskamm:
> Hi Even and PSC members,
>
>
> I am forwarding this email to the dev list as changes / features like
> these need to be voted on by the PSC.
>
> When it comes to the conclusion that things get integrated in mapproxy,
> me and the PSC of course can review the code.
>
> @PSC:
>
> Please read through the mail below and provide your thoughts and votes
> regarding the general idea of having a plugin system in mapproxy.
>
> I think the technical details need to be discussed afterwards on this list.
>
>
> Greetings,
>
> Johannes Weskamm
>
>
>
>
>
> -------- Weitergeleitete Nachricht -------
>
> Hello,
>
> I don't think we've already met before, so let me introduce quickly. I'm
> Even Rouault, the lead developer of GDAL/OGR and owner of a small
> consultancy in France, Spatialys (http://www.spatialys.com/en/about/).
>
> Recently I've done an exploratory work for CNES to add new capabilities
> to MapProxy, to add the support for a new standard, called HIPS, used by
> the planetology and astronomy communities, as a MapProxy source and
> service, and bridging with the traditional OGC protocols (WMS, WMTS...):
> that is e.g. exposing a WMS source as a HIPS service, and vice-verca.
> The sponsor has presented a bit this context in
> https://lists.osgeo.org/pipermail/mapproxy-dev/2022-March/000039.html .
>
> This work has been done in a branch forked from MapProxy master and
> which lives at https://github.com/rouault/mapproxy/tree/hips
>
> We acknowledge that the field domain of HIPS is probably too specific to
> gain enthusiasm for the overall MapProxy community to be merged into
> MapProxy master. So I was thinking that one way of solving this would be
> to put the HIPS specific code in a separate Python project, that would
> be managed outside of the MapProxy community. To do so, we need first to
> add to MapProxy capabilities of handling plugins, as unless I've missed
> something, this is not available currently. That is when MapProxy sees
> in its configuration file a service type or source type, it doesn't
> handle, it would query registered plugins and delegate to them. We would
> need plugin capabilities to also handle add new entries in the /demo
> service as well, and register new commands to mapproxy-util.
>
> It looks like you're one of the currently active developers of MapProxy,
> so I was wondering if, assuming you think it would be a good idea and an
> accepted approach, you would be interested in:
>
> a) either reviewing and merging future code I would develop to add such
> plugin infrastructure to MapProxy that I would develop (the way that
> pytest uses a dedicated entry_point to register a plugin to pytest core
> seemed an interesting idea to borrow:
> https://docs.pytest.org/en/6.2.x/writing_plugins.html#making-your-plugin-installable-by-others)
>
> b) or do that work yourself
>
> and what the associated cost would be.
>
> In either case, the creation of the mapproxy-hips plugin itself would
> remain on my side.
>
> Option a) would have my slight preference given that it would minimize
> back-and-forth interaction and I could make sure that the plugin
> capabilities added to the core meet the needs of the plugin
>
> I'm happy to further discuss with you if you have interest and questions.
>
> Best regards,
>
> E. Rouault
>
-- 
Dipl.-Geogr. Johannes Weskamm
  — Anwendungsentwickler —

  terrestris GmbH & Co. KG
  Kölnstraße 99
  53111 Bonn

  Tel: +49 (0)228 / 96 28 99 -51
  Fax: +49 (0)228 / 96 28 99 -57

  Email: weskamm at terrestris.de
  Web: https://www.terrestris.de

  Amtsgericht Bonn, HRA 6835
  Komplementärin: terrestris Verwaltungsgesellschaft mbH
  vertreten durch: Torsten Brassat, Marc Jansen
  
  Informationen über Ihre gespeicherten Daten finden Sie auf
  unserer Homepage unter folgendem Link: 
  https://www.terrestris.de/datenschutzerklaerung/