[packagekit] Multiple entries to WhatProvides and SearchFile

[Adrien Bustany]

El 23/09/09 05:37, Richard Hughes escribió:
> Whilst converting gnome-packagekit, I'm trying to push back features
> into glib2 (and the daemon) that make logical sense, rather than
> duplicate the functionality in every GUI client. One example is the
> font installer code.
>
> This needs to do WhatProvides on a string array, rather than a single
> string. It makes the GUI client much more complicated as it has to
> send off multiple requests, and wait for them all the come back with
> results. In this case if a single request doesn't match it's not
> classed as failure, but the remaining results are returned. The GUI
> client then has to filter duplicate package_ids.
>
> For 0.5.x I propose allowing WhatProvides and the Search* methods to
> be sent multiple&requests&joined&up&with&ampersands, which the
> backends can split and return results for. For 0.6.x I propose making
> the WhatProvides and Search* methods take string array rather than a
> string, which allows basic ORing of data (which breaks API, but makes
> the API less magic). This would allow us to do
> SearchGroup(["games-gui","games-text") in one method without having to
> do two searches, and then remove the duplicates manually (and breaking
> the filters in some cases, e.g. newest). This would then match the
> Resolve semantics, where you can do Resolve(["DeviceKit","devicekit"])
> and get the correct package_id for debian and fedora.
>
> The only need to do seporate requests would be if the application
> needs to check that all provides exist, or if the client needs to know
> what request matches what package. Both of these seem much less likely
> than the "give me anything that matches" use case.
>
> 99% of the actual real world users for SearchName, WhatProvides etc.
> only ever use one parameter as the search term at a time, and so not
> converting a backend for the next release wouldn't actually break
> anything, but would prevent us from using the feature in the future.
>
> Comments welcome. Please don't change backends yet until we've reached
> a consensus. Thanks.
>
> Richard.
> _______________________________________________
> PackageKit mailing list
> PackageKit at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/packagekit
>   
I don't remember if it's been already discussed, but why do we still use
string separators like &, ^ etc. while DBus supports lists and hashes ?
Performance reasons ?

Cheers

Adrien