|
»
« Return to Thread: Extended package information in PEAR REST interface
Re: Extended package information in PEAR REST interface
by Daniel O'Connor
::
Rate this Message:
On Fri, Mar 9, 2012 at 4:14 PM, Christian Weiske <cweiske@...> wrote:
> Hi,
>
>
> The PEAR installer uses, as most of you know, a REST interface to
> channel servers[1]. It consists of several XML files at defined
> locations.
>
> One of the XML files contains information about the package: Name,
> Description, License, Authors. It's at p/$package/info.xml, e.g. [2].
>
> [1] http://pear.php.net/manual/en/core.rest.php
> [2] http://pear.php.net/rest/p/net_webfinger/info.xml
>
>
> What I'm longing for is a way to discover information like the package
> home page URL, as well as the package's public code repository URL (as
> well as its code http interface URL).
>
> This information are very important for channel server aggregators that
> have been in the talk for a while.
> One aggregator is http://pyr.us/ written by Brett Bieber and used by
> Pyrus' "search" command to find packages across multiple channels.
>
> I'd like to give it a nicer web interface, and for that we need at
> least have a link to the package homepage.
>
> ----
>
> The question now is where to put that information. The DOAP
> project [3] already defines a schema to express such information, and
> we should re-use that. PEAR actually exports DOAP already, just add
> "/doap" to a package homepage[4].
>
> [3] https://github.com/edumbill/doap/wiki
> [4] http://pear.php.net/package/Net_WebFinger/doap
>
> The location of this information is the standing issue. I have several
> ideas:
>
> 1. Add another file to the REST interface, call it
> e.g. p/$package/doap.xml
> This means a new version (REST 1.5) of the PEAR channel server REST
> specs, but probably the least problems with existing client and
> channel server implementations. It might also be seen as cleaner.
>
> 2. Put that information into r/$package/info.xml in the DOAP namespace.
> This would mean we just have to adjust the XSD schema and are set.
> The tags would be optional. No new REST version needed.
>
> Only one counter argument comes to mind: The REST files were
> designed with bandwidth in mind, which means they are as small as
> possible (tag names like "c" or "n"). Adding DOAP information, that
> are unnecessary for most channel server clients, would mean a slight
> increase in bandwidth.
>
Not fussed about either approach or bandwidth implications. I'd probably go
for the incremental change (loosen xsd).
Am more interested in the different servers out there. I mean, we can send
in a pull request to Pirium and fix it in pearweb easily enough; but
there's a few other implementations around the place - some maintained,
some not.
As a different random thought, there's (also) things like
https://github.com/gkellogg/github-lod - so you can start at the github
repo and work backwards to generate the doap - which could be used to infer
project A owl:sameAs webpage B.
> Hi,
>
>
> The PEAR installer uses, as most of you know, a REST interface to
> channel servers[1]. It consists of several XML files at defined
> locations.
>
> One of the XML files contains information about the package: Name,
> Description, License, Authors. It's at p/$package/info.xml, e.g. [2].
>
> [1] http://pear.php.net/manual/en/core.rest.php
> [2] http://pear.php.net/rest/p/net_webfinger/info.xml
>
>
> What I'm longing for is a way to discover information like the package
> home page URL, as well as the package's public code repository URL (as
> well as its code http interface URL).
>
> This information are very important for channel server aggregators that
> have been in the talk for a while.
> One aggregator is http://pyr.us/ written by Brett Bieber and used by
> Pyrus' "search" command to find packages across multiple channels.
>
> I'd like to give it a nicer web interface, and for that we need at
> least have a link to the package homepage.
>
> ----
>
> The question now is where to put that information. The DOAP
> project [3] already defines a schema to express such information, and
> we should re-use that. PEAR actually exports DOAP already, just add
> "/doap" to a package homepage[4].
>
> [3] https://github.com/edumbill/doap/wiki
> [4] http://pear.php.net/package/Net_WebFinger/doap
>
> The location of this information is the standing issue. I have several
> ideas:
>
> 1. Add another file to the REST interface, call it
> e.g. p/$package/doap.xml
> This means a new version (REST 1.5) of the PEAR channel server REST
> specs, but probably the least problems with existing client and
> channel server implementations. It might also be seen as cleaner.
>
> 2. Put that information into r/$package/info.xml in the DOAP namespace.
> This would mean we just have to adjust the XSD schema and are set.
> The tags would be optional. No new REST version needed.
>
> Only one counter argument comes to mind: The REST files were
> designed with bandwidth in mind, which means they are as small as
> possible (tag names like "c" or "n"). Adding DOAP information, that
> are unnecessary for most channel server clients, would mean a slight
> increase in bandwidth.
>
Not fussed about either approach or bandwidth implications. I'd probably go
for the incremental change (loosen xsd).
Am more interested in the different servers out there. I mean, we can send
in a pull request to Pirium and fix it in pearweb easily enough; but
there's a few other implementations around the place - some maintained,
some not.
As a different random thought, there's (also) things like
https://github.com/gkellogg/github-lod - so you can start at the github
repo and work backwards to generate the doap - which could be used to infer
project A owl:sameAs webpage B.
« Return to Thread: Extended package information in PEAR REST interface
| Free embeddable forum powered by Nabble | Forum Help |
