FWIW I think that refactoring to make the internal API match an ideal web services API is good in principle. However we may need to change our coding style substantially to end up with an ideal web services API - if you examine the EC2 API, which is nice to work with, to do fast operations on multiple objects is ingrained - its not ingrained for our local API.
And there is the issue I think: what makes a great web services API is fundamentally different to what makes a great in-app-server API. The latency and bandwidth constraints are radically different. For instance, in a web services API consumer, you want the server to do as much filtering as possible, but then return *all* the relevant data at once. Round trips are terrible. (350ms from here). In a in-app-server API you probably want an object model, with methods on self, rather than collections that mutate a set of objects. -Rob _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
