[packagekit] GetMimeTypes API addition?

[Richard Hughes]

On Mon, 2008-10-06 at 07:29 +0200, Tim Lauridsen wrote:
> but the meta-packages is the same as a collection, this is why i use
> GetCollections.

Only for the yum backend -- this has to be an abstract interface.

> One other difference is that you can do a "search-group none @groupid"
> to get the packages in the group, you cant do that with
> the 'groupid;;;meta".
> you can to both InstallPackages('groupid;;;meta") and
> InstallPackages(''@groupid;;;')

Sure that's very specific to the yum backend. You don't want this layer
of implicit knowledge.

What's the new group API designed to do: Return a custom nested set of
groups. I don't think you want to link in any other logic.

> > CategoryNode(s=parent, s=id, s=icon, s=name)
> >   
> i dont see the need of the parent.

Well, you don't wand to encode the logic that "the left part of the id
will be a substring of the parent -- you don't want to enforce what an
ID looks like as you'll be using the substring in SearchGroup.

There's nothing wrong with this for instance:

S:CategoryNode("@^games", "@boardgames", "board-games", "Board Games")

So if you click on the parent, you do SearchGroup ("@^games") and if you
click on the child you get SearchGroup ("@boardgames") -- it's up to the
backend what input format they want to accept.

> > Then you only need to send one request to the server, and you get one
> > set of requests back, and you get an n-deep tree without hardcoding lots
> > of policy in the API.
> > 
> > It would be trivial to handle in python, and slightly trickier to do in
> > C.
> >   
> We could limit the tree to 4 levels and always send 4 level categories
> to make it easier to decode in C :)

No, you can't enforce such things in the API. The remit for a new group
API is to get 100% custom group menus, and we shouldn't put such limits
on the new API, else it's as bad and hardcoded as the old one.

> GetCategories() return the Categories as a 4 level tree.
> GetCollections(catid) returns the collections in a given level in the
> tree.
> SearchGroup(filter,'@groupid') returns the packages in the group
> (mandatory,default, optional and conditional)
> InstallPackages('@groupid') install the group (only the mandatory and
> default packages)
> 
> in time we can replace the use of SearchGroup(filters,'collections')
> with GetCollections("") and deprecate the 'collections' group enum.

No, I don't think this is a good idea -- there's no reason why a backend
couldn't do something different for the collections group. For instance
collections could be mapped to just return specific vendor groups,
nothing to do with any distro mappings.

You have to remember that any new API can't just be added in a specific
way just because it's done that way in yum. If for instance poldek has
five level comps, then we shouldn't limit this in the API.

Richard.