Local:// protocol for Xlinks
| Date | 2012/09/14 |
| Contact(s) | Jesse Eichar |
| Last edited | |
| Status | committed/merged |
| Assigned to release | 2.9.x |
| Resources | Jesse personal time |
| Code | https://github.com/jesseeichar/core-geonetwork/commits/feature/local-protocol-xlinks |
| Ticket | #1122 |
Overview
For performance and portability this proposal adds a local:// protocol for xlinks. When the Xlink processor encounters this protocol, the processor will directly invoke dispatch on the dispatch manager, instead of making a more expensive http request.
Proposal Type
- Type: XLink
- App: Jeeves
- Module:
Links
- Email discussions:
- IRC discussions:
- Related work:
Voting History
- None as yet
Proposal
For performance and portability this proposal adds a local:// protocol for xlinks. When the Xlink processor encounters this protocol, the processor will directly invoke dispatch on the dispatch manager, instead of making a more expensive http request.
The benefit of using local:// protocol are three fold.
- Performance. The request is made without having to write to and from a socket.
- No new threads need to be spawned to resolve local:// xlinks
- Portability. The server url is not part of the href so the server name, port and even the servlet name can be changed without having to update the xlink hrefs.
In the normal case the behaviour is the same. This just adds the option of using local:// hrefs.
The difference between local/relative hrefs and local:// hrefs are: local/relative hrefs are local within a metadata document. local:// get XML from any service like: local://keyword.get?thesaurus=123&id=123
Backwards Compatibility Issues
Minor Changes to the Processor and ServiceContext API
Risks
Participants
- As above
