The Question Support API project is in good shape, though not complete or even really ready for use by any but the most brave. The focus of development thus far has been on a single backend working well and designing a (hopefully) future-compatible API.
Currently the API supports grabbing questions from files on disk, or over http/ftp (anything supported by python's urllib.urlopen), parsing the GIFT[1] format (partially, there are still some rough corners here) and returning a list of question objects. Currently only multiple-choice and true/false (as a subset of multiple-choice) questions work completely, the remaining question types need further implementation work. Future work will include finishing implementation of the remaining question types and more fully supporting the GIFT input format. (Including partial credit and answer comments.) After a solid implementation of the above is finished the plan would be to extend the API by implementing additional backends for question sources and formats as well as supporting additional metadata and question types (including images and rich-content in questions as implementation time and skill permit). At least two members of the RIT Project team will continue to work on the API in some capacity, though not full-time or as an independent study; just a normal volunteer developer role. (In particular, I am graduating, so I'm probably going to not be too active for a while until I sort everything else out.) It would be nice to get another developer to pitch in on some of the project's goals — even if someone just wants the API to support a particular format, they should feel free to implement it. One final note, the API still has the problem of the Sugar Activity security model to contend with; each activity that uses the API will end up bundling a rather large amount of code (due to dependencies the API contains). It would be nice if there was some mechanism for Activities to require separate bundles in some way (sha1 verified .xo file?) in order to eliminate redundancy. It's mostly just a gripe from the perspective of trying to build out-of-core libraries for Sugar. It's not a barrier to the API, just an unfortunate redundancy. Greg S. _______________________________________________ FourthGradeMath mailing list [email protected] http://lists.sugarlabs.org/listinfo/fourthgrademath
