More gStats
I have not worked on gstats in a while and it definately needed some improvements. I found myself struggling with the UI a lot and after chatting with Graff on irc I decided to drop the webUI entirely and go RESTful. Ewwww REST….
I actually hate REST because all of its supporters claim it is ‘Teh awesome!’ but so very few can tell me why in any sort of convincing manner. ‘It doesn’t have all the overhead of SOAP!’, ‘It uses HTTP!’…these are not convincing arguments. Anyway I figured I’d give it a try.
gStats now has no real webUI. Most of the data retrieval functionality is written (aka HTTP GET) using old data in the cache so you can do queries like /api/cp/sys-apps/portage and it will return some XML that describes sys-apps/portage’s installation history. Also available is /api/arch/x86 which will return some XML describing x86’s installation info.
I am working on writing POST methods; although I noticed I have a slight issue. Users have hosts with 100’s of packages installed. REST is kind of limiting in this regard; right now I store arches and cps (category/package strings) and via the rest interface you can POST new arch data (not really allowed at this point as it would overwrite old data in my reckoning) and you can POST new cp data (being worked on). But the cp POST model right now kind of takes a cp as a key; maybe I should drop that requirement.
Currently:
POST /api/cp/sys-apps/newpackage
some XML describing a single cp named sys-apps/newpackage
New Idea:
POST /api/cp
some XML describing multiple CPs

Leave a comment
You must be logged in to post a comment.