[ckan-discuss] Tag_count per group / packagecount in grouplist

[John Bywater]

Friedrich Lindenberg wrote:
>> But in any case, it might be nice to pass a list comprehension to the server, and have the results returned in one call. So I wondered whether a "List Comprehension API" would make sense?
> 
> I don't get this - are you proposing to allow the client to pass actual code to the server (or a sufficiently large set of parameters for this to make sense)? That would not make things very RESTish, I think - but I'm eager to hear more about what you are proposing! 
> 

I was just wondering whether supporting a list comprehension syntax 
would be useful, to cut down bandwidth in cases just like this.

For example, when to get all the package titles, you have to get all the 
ids, and then get all the entities, and then get the title from each entity.

We could imagine a request something like:

($id, /package/$id/title) for $id in /package

which could return something like:
[(UUID, TITLE), (UUID, TITLE), (UUID, TITLE), ...]


Looking at what Martin asked for:

1. "To get a tag-list, with count, for a specific group"

I'm not sure whether we want to get a set of all tags on the packages of 
a group? Or a list of the tags used on each package of a group?

For the first one, we publish a new resource locator:
/group/$id/tags

For the second case, we could imagine a list comprehension:
[($id, /package/$id/tags) for $id in /group/mygroup/packages]


2. "To show a package count per group for a page of 30 groups"

We could imagine a list comprehension, like this:
[/group/$id/packages/count for $id in [id0, id1, id2, ... , id29]]

where the id0, id1, etc. are the items in the page.


>> That's not to argue against faceted search. Indeed, let's establish requirements before shaping up a solution. :-)
> 
> As an intro to the kind of data that facets expose, let me point you at http://wiki.apache.org/solr/SimpleFacetParameters#Facet_Fields - this to me looks very much like the thing Martin is asking about - but I might be rorschaching there ;-) 
> 

Yes, it looks good. I'm not against this. We could adopt a faceted 
search query syntax, regardless of anything else.

But I wondered whether we could make further use of the published API 
resource locators.

There seems to be two separate concerns: how to implement efficient 
filtering when the filter is complex; and how to implement a good way 
for a user of the API to express the filter.

I mean, if you're looping over the result of one call with a load of 
other calls, it might be nice to cut out most of the to-ing and fro-ing, 
with a list comprehension, just like in programming languages. At this 
point, you know the resource locators, so putting them into a list 
comprehension would express what you're trying to do. Switching to a 
whole new syntax might not feel so smooth. But I'm just guessing.

J.

> Friedrich