On Tue, Mar 23, 2010 at 9:14 AM, Garrett D'Amore <garrett at damore.org> wrote: > > The Volatile binding for the library and lack of any documentation for > external interfaces are going to severely limit its use in cross > consolidation project. Maybe that's not a bad thing. >
The project homepage says: libgdata is a GLib-based library for accessing online service APIs using the GData protocol ? most notably, Google's services. It provides APIs to access the common Google services, and has full asynchronous support. The dependency on GLib says to me that this is a GUI focused API set that will find few non-GUI uses, especially since there are API libraries available from Google for Java, JavaScript, PHP, Python and Objective-C... Google defines the protocol: http://code.google.com/apis/gdata/ What is the Google Data Protocol? The Google Data Protocol is a REST-inspired technology for reading, writing, and modifying information on the web. Many services at Google provide external access to data and functionality through APIs that utilize the Google Data Protocol. The protocol currently supports two primary modes of access: * AtomPub: Information is sent as a collection of Atom items, using the standard Atom syndication format to represent data and HTTP to handle communication. The Google Data Protocol extends AtomPub for processing queries, authentication, and batch requests. * JSON: Information is sent as JSON objects that mirror the Atom representation. The Google Data Protocol provides a secure means for external developers to write new applications that let end users access and update the data stored by many Google products. External developers can use the Google Data Protocol directly, or they can use any of the supported programming languages provided by the client libraries. This says to me that the APIs are at least Uncommitted and probably Committed. In a perfect world, we would have a project that added all these APIs to OpenSolaris as a coordinated packaging exercise. -John