launchpad-dev team mailing list archive

["Francis J. Lacoste" <francis.lacoste@xxxxxxxxxxxxx>]

On March 24, 2011, Martin Pool wrote:
> Hi, thanks for raising this.
> 
> Nearly any practical operation on bugs is going to take O(n) round
> trips, because nearly anything will want both the bug and the
> bugtask(s) and you cannot get them both in batches.  It would be good
> to work out a way to send them all at once to avoid potato
> programming.  I don't know about the limitations of the mapping layer
> but conceptually and in terms of network representation it should not
> be that hard to say that tasks are value objects sent inline with the
> enclosing bug.  Fixing this kind of thing would speed up many clients,
> and I expect also reduce the server load.  Similarly for merge
> proposals.

That's what is covered by the expand/filter proposal.


> I find it kind of weird that Launchpad in some ways is quite pedantic
> about HTTP and being restful, and then in others has very rpc-like
> non-restful methods to get collections and do searches.  I would like
> if the URLs looked more like collections, ie
> /~mbp/bugs/status=In+Progress/ or something.  It might make them more
> cacheable, and more understandable for client developers.  I have a
> sense that people do not look enough at what actually goes across the
> wire, and things would be better if they did.
> 

That was the original proposed design and still a direction that we wanted to 
take the web service into. But that purely REST model was put on hold because 
it was thought that 

a) creating one object model is hard already, let's not have two (internal + 
external); so have minimal skew between internal and external API

b) getting this REST stuff is hard, much simpler to go with what people know: 
methods

Please don't try to argue why these two assumptions were bad. I think we have 
seen the limitations of those in practice.


-- 
Francis J. Lacoste
francis.lacoste@xxxxxxxxxxxxx

Attachment: signature.asc
Description: This is a digitally signed message part.