ZYpp allows to hook and extend some functionality by adding scripts in the plugins location
Depending on the plugin type, they may need to communicate with libzypp via a protocol. This protocol is based on STOMP (Streaming Text Orientated Messaging Protocol).
See this blog post]
For now, service plugins concept is that you call them and they return a repo list.
- Question:* Use the protocol here too, and return the repo list in the body?
Url resolver plugins
Url resolver plugins convert urls of scheme "plugin" into the output of the plugin named $name using the protocol. Thanks to the protocol, each header returned is also added as HTTP headers. The current protocol sequence is:
ZYpp sees a url of the format:
And plugin named foo is executed and called with the following protocol:
RESOLVEURL param1:val1 param2:val2 ...
The plugin answers:
RESOLVEDURL: header1:val1 header2:val2 ...
And this url is used instead.
You have a repository with url:
The script looks which distribution you have installed, and via SLP finds the right repositories in the lan and selects the update one and returns it url. But in addition, it adds a header with the update status that can be collected on the server side.
This type of plugin can be combined with service plugins, because a local service could return a list of repos like this:
[distro] name=Distribution repository baseurl=plugin:lan?repo=distro
[update] name=Update repository baseurl=plugin:lan?repo=update
In this example, the service plugin could have inmediately resolved the urls and returned
[distro] name=Distribution repository baseurl=http://realurl
But the url resolver allows also to add headers to the request.