URL_ProtocolRegister (changes)
Showing changes from revision #2 to #3:
Added | Removed | Changed
URL_Fetcher
SWI Calls
URL_ProtocolRegister
URL_ProtocolRegister
Register a protocol module with the URL module.
(SWI &83E20)
| Entry | ||
|---|---|---|
| R0 | Flags: | |
| Bit 0 => | If set, R5 contains protocol flags word | |
| Bit 1 => | If set, R6 contains the default port number | |
| Bits 31..2 | Reserved (0) | |
| R1 | Protocol module’s SWI base | |
| R2 | URL fetch scheme supported e.g. “http:” etc. | |
| R3 | Version number * 100 e.g. 116 => version 1.16 | |
| R4 | Informational string. Up to 50 characters of descriptive text, e.g. “Acorn HTTP fetcher” | |
| R5 | Protocol flags word, if R0:0 set. See below | |
| R6 | Default port number, if R0:1 set. See below | |
| Exit | ||
|---|---|---|
| R0 | Flags: | |
| Bits 31..0 | Reserved (0) | |
| All other registers preserved | ||
| SWI is not re-entrant. | ||
| Interrupt status is undefined | ||
Use
This call is used by a protocol fetcher module to register its SWI base and the type of URL that it accepts with the URL module. The SWIs that are accessible from this SWI base are defined in the Protocol module interface documentation. If the module cannot be registered (e.g. another module is already claiming that URL base), then an error will be returned. R3 is an integer version number and R4 is a pointer to a string containing more information which will be displayed by the *URLProtoShow command (or 0 if no descriptive text is provided).
Typically, it will be called during a protocol module’s initialisation code or on a callback set from the module’s initialisation code. If the protocol module is registered successfully, then URL will issue a service call Service_URLProtocolModule_ProtocolModule? to inform any interested modules.
If R0:0 is set, then R5 contains a protocol flags word. This is used to describe to URL how the resolver should treat URLs from this scheme. The current bits defined are:
| Bit | Meaning when set |
| 0 | Path is not UNIX-like |
| 1 | No parsing should be performed on this scheme |
| 2 | Scheme allows “user@” to precede the hostname component |
| 3 | Hash (ASCII 35) allowed in hostname (e.g. for file: URLs) |
| 4 | No hostname component (e.g. mailto: URLs) |
| 5 | Remove leading “..” components in pathname. |
Note that the meanings of set bits are such that zero is a reasonable value to pass for unknown schemes. Note that if URL is requested to resolve URLs using schemes unknown to it, it will assume a protocol flags word value of zero. This may lead to inconsistent behaviour depending on whether the protocol module is loaded or not.
If R0:1 is set, then R6 contains the default port number for this scheme. This is used by the URL resolving code to determine if explicitly specified port numbers can be elided from the URL. For example, when constructing the canonicalised form of “http://www.acorn.com:80/”, the port bit is dropped as it serves no useful purpose, leaving “http://www.acorn.com/”.
The URL module is primed with knowledge of the following protocols:
mailto:, telnet:, finger:, file:, filer_opendir:, filer_run:, local:, gopher:, ftp:, http:, https:, whois:It is not necessary for modules implementing those protocols to set either flag bit and hence there is no need for them to set R5 or R6.
Social
and
ROOL Store
Buy RISC OS Open merchandise here, including SD cards for Raspberry Pi and more.