On 15 January 2011 05:00, Stephan Beal sgb...@googlemail.com wrote:
If there is an outcry of support for exporting certain fossil data as JSON,
i would ask the group to propose JSON schemas for the relevant areas. (i'm
thinking: timeline, maybe wiki pages... what else?).
In terms of schemas - my starting point would be to look at the ones that
already exist in order to make it easier for people with code linking to
them to switch to fossil. Taking the minimalist approach already taken to
the wiki, would be the way to go - no need to support every feature. If
nothing else we'll be borrowing from actual use cases discovered in other
communities.
Overall you could look at the Trac XMLRPC
pluginhttp://trac-hacks.org/wiki/XmlRpcPlugin#APIUsage- which
exposes most of Tracs functions via XML. I'ts been around a good few
years, and should give a good idea of use cases for Fossil RPC (it's the
interface I'e used before). naturally you want to look at a JSON output /
input rather than the XML.
With regards the JSON schema - I think it would be very useful to use a
simplified version of the MediaWiki JSON output
formathttp://www.mediawiki.org/wiki/API:Data_formats#Output.
This would be very useful to import documentation for projects as there is a
lot of good starting material on WikiPedia regarding programming. It would
be very useful therefore to be able to take an output like:
- *
api.php?action=queryprop=revisionsrvprop=contentformat=jsontitles=Representational_State_Transferhttp://en.wikipedia.org/w/api.php?action=queryprop=revisionsrvprop=contentformat=jsontitles=Representational_State_Transfer
*
This means fetch (*action=query*) the content (*rvprop=content*) of the most
recent revision of the Representational_State_Transfer page on wikipedia in
JSON format (*format=xml*).
Being able to grab this content and insert it into a Fossil wiki page using
and existing library, and simply changing the endpoint for the web service
would be very useful. It also provides useful test data to code against. How
about starting with this, in terms of RoadMap but implement a simplified
subset of parameters, and ignore returned data fields that are not relevant.
NB - with the Wikipedia content, it would be good practice to respect the
license terms and automatically import the pages history log, and a link
back to the original article. This can be scripted, but it may be worth
considering in the schema so that the right json export from WikiPedia can
automatically be imported with accreditation and backlinks to the WikiPedia
article.
- see http://meta.wikimedia.org/wiki/Help:Transwiki
On the remote talk page, copy and paste the original page's history log
under a new heading (see
Talk:Wikistresshttp://meta.wikimedia.org/wiki/Talk:Wikistressfor an
example). This is to adhere to the requirements of Wikimedia's
license http://meta.wikimedia.org/wiki/GFDL, which requires that a
record be made of all authors. If there are only a few authors, you can note
them in your creation edit
summaryhttp://meta.wikimedia.org/wiki/Help:Edit_summaryinstead.
I'm happy to be a beta tester on this, as i am working on the import export
code for a number of projects, and have experimented with doing this for
Trac.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
