Re: Extended package information in PEAR REST interface

On Fri, Mar 9, 2012 at 4:14 PM, Christian Weiske <cweiske@cweiske.de> 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.