launchpad-dev team mailing list archive

[Jonathan Lange <jml@xxxxxxxxxxxxx>]

On Tue, Nov 17, 2009 at 6:24 PM, Leonard Richardson
<leonard.richardson@xxxxxxxxxxxxx> wrote:
> Aaron wrote:
>> If we're rethinking this stuff, it would be really nice to do further
>> latency-hiding on the request side.  For example, I have a plugin that
>> 1. logs in
>> 2. looks up branch lp:foo
>> 3. looks up branch lp:bar
>> 4. looks up person ~baz
>> 5. creates a merge proposal for merging lp:foo into lp:bar, with ~baz
>> as a reviewer.
>> 6. opens the local browser to the merge proposal URL.
>>
>> Steps 1-4 have no data dependencies, so they could easily be done as a
>> single request.
>
> There's no fundamental reason why steps 2-4 need to trigger HTTP
> requests. launchpadlib has some deferred loading code but it's clearly
> not being triggered in your case. I'd prefer to make launchpadlib
> smarter than to bundle requests that deal with multiple objects. (HTTP
> pipelining is OK, but I don't know if that's what you were thinking.)
>

There are a lot of people in the Ubuntu community who are writing
scripts with launchpadlib (see https://launchpad.net/lpx) and their
number two complaint is how slow it is. I talked to one person at UDS
who has a script that takes hours to figure out the membership in a
team.

On the other hand, I was surprised at just how much interest there was
in our public APIs. Many people came up to me and talked about their
experiences using lauchpadlib.

Some other interesting things from UDS about the APIs
  * Lots of people didn't know about login_with, but think it's really
awesome. They wished we blogged about it or something.
  * Everyone is using launchpadlib, afaict. No one mentioned the raw
HTTP api or implementing a client in languages other than Python.
  * In a plenary session, I did a live demo of coding a launchpadlib
script. It takes quite a while to do a roundtrip.
  * The number one complaint is that the reference documentation is confusing.

jml