• Immutable Page
• Info
• Attachments
• More Actions: Raw Text Print View Render as Docbook Delete Cache ------------------------ Check Spelling Like Pages Local Site Map ------------------------ Rename Page Delete Page ------------------------ Subscribe User ------------------------ Remove Spam Revert to this revision Package Pages Sync Pages ------------------------ Load Save SlideShow

Q & A

Why about those names? restrict vs. refine, and the various combinations of expand, select, and dereference?

• The names are up for discussion, like everything else. [I suggest "restrict and expand", as "refine" implies a two-step process. -LR]

Why do we POST to the expander? The request does not mutate, so I would think GET would be a better verb.

• URL length limitations. We may be asking to expand thousands of URLs at once.

Why get identities (possibly filtered or refined) in one request and get data for batches of identities (expanded) in multiple subsequent requests?

• it makes getting a filtered set transactional.
• it makes working with the result--len, walking in reverse, walking in step, and so on--easy, natural, and efficient.
• it can be regular, uniform and unlimited, if we think we can always return the set no matter how big it is, or at least with *really big* sets (we are currently envisioning a limit of 10,000).
• it continues the basic select/expand model of encouraging users to think about working with collections, and not individual entities.

Why prefer not to use strings for identifying sub-elements? (the string "people['foo'].assigned_bugs" vs the expression launchpad.people['foo'].assigned_bugs)

• Prettier
• Client-side typo reporting
• help() and dir() will work on them
• Tab completion

Why prefer immutable query?

• Easier to reason about derived queries: always a new copy, no possibility of mutating a query another query is based on

Why prefer immutable results?

• Snapshot of response; shows that it is not transactional
• Clear parallel to a browser response
• No partial updates of sets (i.e., the data in a given response collection will always be self-consistent because it was fetched inside a transaction. This is actually stated a little strongly, and therefore the argument is weakened: the set membership is transactional, but the expansions are batched.)

Potential worries of immutability:

• may cause memory problems. Can come up with ways to alleviate if a problem (e.g., unchanged bits are kept) but hopefully we won't have to.
• people may want to union results. To alleviate, provide an explicit function that does this, returning a new collection. Members will be reused, so the cost should be cheap.

When might you want to get a single specific item, expanded?

• You are looking for a specific project, like Ubuntu; or specific person, like yourself; and just want to expand it.

When might you want to get a bunch of specific heterogeneous items, all at once, expanded?

• You are building a "page" for GroundControl or a hypothetical all-AJAX Launchpad. You need a bunch of things for the page, and you want it as efficiently as possible. Leonard's syntax proposes a generic "expand" resource, so we can do it in the webservice.

• This allows the server to provide more data per request.
• The server can probably use URL patterns to group requests so that they are performed in a group, efficiently

Why can the user request more references be expanded than will likely actually be expanded?

• It works out nicely if the server can return an arbitrary number of reponses for a given request. The server can decide to send less or more depending on current system environment, very dynamically. The user-facing aspect of this is that DEREF will not necessarily return the number of values they pass in. batchDEREF becomes the only way to do it, for better or worse.
• In terms of the possible optimization of the server telling the client that it can take more requests than it just received, we might do it in some future revision (heterogeneity might make it more difficult).
• We want to encourage the typical request size to be large, in number of items -- which will practically make it significantly larger than the usual response, it number of items. Put another way, the maximum number of items to be requested can be large, but don't expect to get that number of items back.

Are we initially going to allow people to expand non-leaf-node values?

• My answer is, yeah, probably, or at the very least that is intended initially.

Why does specifying a field in a filter not include it in the Python representation as if you had expanded it?

• reduce surprise. If you want it, include it in the expansion.