On Wednesday 19 May 2010 02:25:35 Robert Collins wrote: > 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.
To some extent I agree, but the performance implications still apply to the internal API. We do quite a lot of utility code that will pull in many objects at once. ORMs don't exactly encourage that :( _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
