Mailinglist Archive: zypp-devel (227 mails)
| < Previous | Next > |
[zypp-devel] query abstraction level over pool
- From: Josef Reidinger <jreidinger@xxxxxxx>
- Date: Thu, 03 Apr 2008 14:13:15 +0200
- Message-id: <47F4C9DB.10507@xxxxxxx>
Hi,
I have this idea when thinking about locks.
problem:
ui have direct access to pool (jano say me, that ma and schubi works on it). And with locks is problem, that libzypp don't know what ui wants. ma propose[0] have on solvable some bits for was-locked. Problem with it is, that ui know what they want, but pass to libzypp only result and is hard to recognize what ui want (f.e. ui want locks all package for gcc -> ui locks all gcc solvable X ui wants locks everythink with gcc -> if no gcc patch is avaible then ui locks same solvables and I cannot recognize what they want).
sollution (my idea):
ui communicate with pool by messages (late query) representing query.
So if ui wants locks everything for gcc it fill query with name gcc and call lock with this query as param.
If ui wants locks only packages gcc, they fill query with name gcc and kind package.
If ui wants locks gcc-4.1.1 they fill query with name and version.etc.
This can be also apply to install or uninstall. ui pass filled query what they want.
advantage -
clear api - only few functions is needed, implementation has been driven by query.
uniform calls - you fill same query for locks, search, install, uninstall, whatever you want and only pass ti to right function.
libzypp know what ui wants - they fill send what they want not result
of it
disadvantage -
byrocracy?
depends on query versatility
lock relevant part
for locks api is still problems remove lock. ma propose something[0], but I think that it have problem that only guess if lock lock what user want unlock. I think better is save query passed by ui and when they want remove somethink it also pass query. Search thru locks storage and try find what query have non-null intersect of results. If this query is identical (typical if you use one ui) then query is remove. If query have same results but isn't identical then call callback if user really want remove it. If results isn't same show callback but enriched with effected package and let decide on ui (user) if they want remove this lock which also remove more locks. Any other suggestion?
thanks for attention and comments
Pepa
[0] http://lists.opensuse.org/zypp-devel/2008-03/msg00080.html
--
To unsubscribe, e-mail: zypp-devel+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: zypp-devel+help@xxxxxxxxxxxx
I have this idea when thinking about locks.
problem:
ui have direct access to pool (jano say me, that ma and schubi works on it). And with locks is problem, that libzypp don't know what ui wants. ma propose[0] have on solvable some bits for was-locked. Problem with it is, that ui know what they want, but pass to libzypp only result and is hard to recognize what ui want (f.e. ui want locks all package for gcc -> ui locks all gcc solvable X ui wants locks everythink with gcc -> if no gcc patch is avaible then ui locks same solvables and I cannot recognize what they want).
sollution (my idea):
ui communicate with pool by messages (late query) representing query.
So if ui wants locks everything for gcc it fill query with name gcc and call lock with this query as param.
If ui wants locks only packages gcc, they fill query with name gcc and kind package.
If ui wants locks gcc-4.1.1 they fill query with name and version.etc.
This can be also apply to install or uninstall. ui pass filled query what they want.
advantage -
clear api - only few functions is needed, implementation has been driven by query.
uniform calls - you fill same query for locks, search, install, uninstall, whatever you want and only pass ti to right function.
libzypp know what ui wants - they fill send what they want not result
of it
disadvantage -
byrocracy?
depends on query versatility
lock relevant part
for locks api is still problems remove lock. ma propose something[0], but I think that it have problem that only guess if lock lock what user want unlock. I think better is save query passed by ui and when they want remove somethink it also pass query. Search thru locks storage and try find what query have non-null intersect of results. If this query is identical (typical if you use one ui) then query is remove. If query have same results but isn't identical then call callback if user really want remove it. If results isn't same show callback but enriched with effected package and let decide on ui (user) if they want remove this lock which also remove more locks. Any other suggestion?
thanks for attention and comments
Pepa
[0] http://lists.opensuse.org/zypp-devel/2008-03/msg00080.html
--
To unsubscribe, e-mail: zypp-devel+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: zypp-devel+help@xxxxxxxxxxxx
| < Previous | Next > |