Tracks has an API, That is good. It is a RESTful API, that is better. The way I understand the current implementation is that the client requests a list from the API. It then receives the entire list. Basically no different then the index page but with XML instead.
This makes things quite versatile. However it also means that subsequent requests will get the entire dump all over again. A solution would be to allow a list of ID's to be posted to such a request and the server would only return items that had changed, added, or deleted. Saving space on the transfer of information. I ask this because I was in the planning stage for an application that will use the API to interact with Tracks. It will store a copy of the items (pulled through the XML requests) as to allow a user to work on the items offline and the "sync" back to the server. The only way I see this happening is to add that functionality to the server code. I'm asking whether the development community would be interested in such features. In other words If I fork and pull-request my additions to the API specs is the community interested OR does this go against the design principles for Tracks? (My app wold be written in JavaScript so I was planning to add json APIs to this). -- "Doing something is not enough. Doing it right is what we want" - Michael Munger
_______________________________________________ Tracks-discuss mailing list Tracks-discuss@lists.rousette.org.uk http://lists.rousette.org.uk/mailman/listinfo/tracks-discuss
