3party/libzmq
0
0
Fork 0
mirror of https://github.com/zeromq/libzmq.git synced 2024-12-27 15:41:05 +08:00
Code Issues Projects Releases Wiki Activity
libzmq/doc/zmq_has.adoc

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

39 lines
1.1 KiB
Plaintext
Raw Normal View History

Feature: modernize API documentation * migrate from the old, unmaintained "asciidoc-py" tool to the new "asciidoctor" generator * migrate from asciidoc-py syntax to the modern Asciidoc syntax (especially page titles and section titles) * remove the need of "xmlto" utility to create the manpage output; use asciidoctor for that * add HTML output support to the doc/Makefile by using asciidoctor * change API documentation files extension from .txt to .adoc to make it more explicit that they are Asciidoc-encoded (as a bonus several IDE plugins will autodetect the .adoc format as Asciidoc) * remove asciidoc.conf: asciidoctor does not support that; this also required replacing the macro linkzmq into all documentation pages * add a new Github action CI do deploy to Github Pages the static HTMLs produced by Asciidoctors * removed references to the "xmlto" and "a2x" tools from the build and packaging systems: Asciidoctor can convert the documentation directly to e.g. pdf (via extended converters) and anyway there was no code/target for using "xmlto" and "a2x" tools anyway
2023-10-21 01:50:38 +02:00
= zmq_has(3)
Problem: need way to probe library capabilities As libzmq is compiled with optional transports and security mechanisms, there is no clean way for applications to determine what capabilities are actually available in a given libzmq instance. Solution: provide an API specifically for capability reporting. The zmq_has () method is meant to be open ended. It accepts a string so that we can add arbitrary capabilities without breaking existing applications. zmq.h also defines ZMQ_HAS_CAPABILITIES when this method is provided.
2014-06-18 15:10:18 +02:00
Feature: modernize API documentation * migrate from the old, unmaintained "asciidoc-py" tool to the new "asciidoctor" generator * migrate from asciidoc-py syntax to the modern Asciidoc syntax (especially page titles and section titles) * remove the need of "xmlto" utility to create the manpage output; use asciidoctor for that * add HTML output support to the doc/Makefile by using asciidoctor * change API documentation files extension from .txt to .adoc to make it more explicit that they are Asciidoc-encoded (as a bonus several IDE plugins will autodetect the .adoc format as Asciidoc) * remove asciidoc.conf: asciidoctor does not support that; this also required replacing the macro linkzmq into all documentation pages * add a new Github action CI do deploy to Github Pages the static HTMLs produced by Asciidoctors * removed references to the "xmlto" and "a2x" tools from the build and packaging systems: Asciidoctor can convert the documentation directly to e.g. pdf (via extended converters) and anyway there was no code/target for using "xmlto" and "a2x" tools anyway
2023-10-21 01:50:38 +02:00
== NAME
Problem: need way to probe library capabilities As libzmq is compiled with optional transports and security mechanisms, there is no clean way for applications to determine what capabilities are actually available in a given libzmq instance. Solution: provide an API specifically for capability reporting. The zmq_has () method is meant to be open ended. It accepts a string so that we can add arbitrary capabilities without breaking existing applications. zmq.h also defines ZMQ_HAS_CAPABILITIES when this method is provided.
2014-06-18 15:10:18 +02:00
zmq_has - check a ZMQ capability
Feature: modernize API documentation * migrate from the old, unmaintained "asciidoc-py" tool to the new "asciidoctor" generator * migrate from asciidoc-py syntax to the modern Asciidoc syntax (especially page titles and section titles) * remove the need of "xmlto" utility to create the manpage output; use asciidoctor for that * add HTML output support to the doc/Makefile by using asciidoctor * change API documentation files extension from .txt to .adoc to make it more explicit that they are Asciidoc-encoded (as a bonus several IDE plugins will autodetect the .adoc format as Asciidoc) * remove asciidoc.conf: asciidoctor does not support that; this also required replacing the macro linkzmq into all documentation pages * add a new Github action CI do deploy to Github Pages the static HTMLs produced by Asciidoctors * removed references to the "xmlto" and "a2x" tools from the build and packaging systems: Asciidoctor can convert the documentation directly to e.g. pdf (via extended converters) and anyway there was no code/target for using "xmlto" and "a2x" tools anyway
2023-10-21 01:50:38 +02:00
== SYNOPSIS
Problem: need way to probe library capabilities As libzmq is compiled with optional transports and security mechanisms, there is no clean way for applications to determine what capabilities are actually available in a given libzmq instance. Solution: provide an API specifically for capability reporting. The zmq_has () method is meant to be open ended. It accepts a string so that we can add arbitrary capabilities without breaking existing applications. zmq.h also defines ZMQ_HAS_CAPABILITIES when this method is provided.
2014-06-18 15:10:18 +02:00
*int zmq_has (const char *capability);*
Feature: modernize API documentation * migrate from the old, unmaintained "asciidoc-py" tool to the new "asciidoctor" generator * migrate from asciidoc-py syntax to the modern Asciidoc syntax (especially page titles and section titles) * remove the need of "xmlto" utility to create the manpage output; use asciidoctor for that * add HTML output support to the doc/Makefile by using asciidoctor * change API documentation files extension from .txt to .adoc to make it more explicit that they are Asciidoc-encoded (as a bonus several IDE plugins will autodetect the .adoc format as Asciidoc) * remove asciidoc.conf: asciidoctor does not support that; this also required replacing the macro linkzmq into all documentation pages * add a new Github action CI do deploy to Github Pages the static HTMLs produced by Asciidoctors * removed references to the "xmlto" and "a2x" tools from the build and packaging systems: Asciidoctor can convert the documentation directly to e.g. pdf (via extended converters) and anyway there was no code/target for using "xmlto" and "a2x" tools anyway
2023-10-21 01:50:38 +02:00
== DESCRIPTION
Problem: need way to probe library capabilities As libzmq is compiled with optional transports and security mechanisms, there is no clean way for applications to determine what capabilities are actually available in a given libzmq instance. Solution: provide an API specifically for capability reporting. The zmq_has () method is meant to be open ended. It accepts a string so that we can add arbitrary capabilities without breaking existing applications. zmq.h also defines ZMQ_HAS_CAPABILITIES when this method is provided.
2014-06-18 15:10:18 +02:00
The _zmq_has()_ function shall report whether a specified capability is
available in the library. This allows bindings and applications to probe
a library directly, for transport and security options.
Capabilities shall be lowercase strings. The following capabilities are
defined:
* ipc - the library supports the ipc:// protocol
* pgm - the library supports the pgm:// protocol
* tipc - the library supports the tipc:// protocol
* norm - the library supports the norm:// protocol
* curve - the library supports the CURVE security mechanism
* gssapi - the library supports the GSSAPI security mechanism
Problem: typo in the zmq_has doc Solution: fix it
2017-01-19 21:00:15 +00:00
* draft - the library is built with the draft api
Problem: need way to probe library capabilities As libzmq is compiled with optional transports and security mechanisms, there is no clean way for applications to determine what capabilities are actually available in a given libzmq instance. Solution: provide an API specifically for capability reporting. The zmq_has () method is meant to be open ended. It accepts a string so that we can add arbitrary capabilities without breaking existing applications. zmq.h also defines ZMQ_HAS_CAPABILITIES when this method is provided.
2014-06-18 15:10:18 +02:00
When this method is provided, the zmq.h header file will define
ZMQ_HAS_CAPABILITIES.
Feature: modernize API documentation * migrate from the old, unmaintained "asciidoc-py" tool to the new "asciidoctor" generator * migrate from asciidoc-py syntax to the modern Asciidoc syntax (especially page titles and section titles) * remove the need of "xmlto" utility to create the manpage output; use asciidoctor for that * add HTML output support to the doc/Makefile by using asciidoctor * change API documentation files extension from .txt to .adoc to make it more explicit that they are Asciidoc-encoded (as a bonus several IDE plugins will autodetect the .adoc format as Asciidoc) * remove asciidoc.conf: asciidoctor does not support that; this also required replacing the macro linkzmq into all documentation pages * add a new Github action CI do deploy to Github Pages the static HTMLs produced by Asciidoctors * removed references to the "xmlto" and "a2x" tools from the build and packaging systems: Asciidoctor can convert the documentation directly to e.g. pdf (via extended converters) and anyway there was no code/target for using "xmlto" and "a2x" tools anyway
2023-10-21 01:50:38 +02:00
== RETURN VALUE
Problem: need way to probe library capabilities As libzmq is compiled with optional transports and security mechanisms, there is no clean way for applications to determine what capabilities are actually available in a given libzmq instance. Solution: provide an API specifically for capability reporting. The zmq_has () method is meant to be open ended. It accepts a string so that we can add arbitrary capabilities without breaking existing applications. zmq.h also defines ZMQ_HAS_CAPABILITIES when this method is provided.
2014-06-18 15:10:18 +02:00
The _zmq_has()_ function shall return 1 if the specified capability is
provided. Otherwise it shall return 0.
Feature: modernize API documentation * migrate from the old, unmaintained "asciidoc-py" tool to the new "asciidoctor" generator * migrate from asciidoc-py syntax to the modern Asciidoc syntax (especially page titles and section titles) * remove the need of "xmlto" utility to create the manpage output; use asciidoctor for that * add HTML output support to the doc/Makefile by using asciidoctor * change API documentation files extension from .txt to .adoc to make it more explicit that they are Asciidoc-encoded (as a bonus several IDE plugins will autodetect the .adoc format as Asciidoc) * remove asciidoc.conf: asciidoctor does not support that; this also required replacing the macro linkzmq into all documentation pages * add a new Github action CI do deploy to Github Pages the static HTMLs produced by Asciidoctors * removed references to the "xmlto" and "a2x" tools from the build and packaging systems: Asciidoctor can convert the documentation directly to e.g. pdf (via extended converters) and anyway there was no code/target for using "xmlto" and "a2x" tools anyway
2023-10-21 01:50:38 +02:00
== AUTHORS
Problem: need way to probe library capabilities As libzmq is compiled with optional transports and security mechanisms, there is no clean way for applications to determine what capabilities are actually available in a given libzmq instance. Solution: provide an API specifically for capability reporting. The zmq_has () method is meant to be open ended. It accepts a string so that we can add arbitrary capabilities without breaking existing applications. zmq.h also defines ZMQ_HAS_CAPABILITIES when this method is provided.
2014-06-18 15:10:18 +02:00
This page was written by the 0MQ community. To make a change please
Replace old website contribution page link with the page of the new website
2023-11-22 23:18:23 +01:00
read the 0MQ Contribution Policy at <https://zeromq.org/how-to-contribute/>.
Reference in New Issue Copy Permalink