Mailinglist Archive: zypp-devel (66 mails)

["Duncan Mac-Vicar P." <dmacvicar@xxxxxxx>]

Hi guys, I need some feedback.

The ultimate goal of this is to be able to have more fine grained
control over the protocols, to make easily to add options that alter the
transfer behavior. A concrete example is range support. So one can ask
for a piece of the file. This could be used to implement changelog
retrieval on real time, as we know from the metadata the rpm header
range, so we can retrieve the header without the payload. Currently most
functions of MediaManager take only the path. Some others also take a
bool (ugh!) to change some behavior.

As inspiration, I checked various similar APIs. The design I like most
is KIO (KDE's vfs). KIO provides two interfaces, one sync, which has
methods like KIO::NetAccess::download(url), and a async one, using jobs.
Jobs carry the operation, options, and the important part: metadata.
Also the jobs signals back errors, success and data events.

The metadata in KIO is a simple map string->string, which is interpreted
by each protocol. Some string are "predefined": (see
kdelibs/kio/DESIGN.metadata [1]) while others are ignored by some
protocols, or turned into headers by others (http for example).

As discussed with Michael, we did not want to use OnMediaLocation here,
because it has too much information which the MediaManager does not need
(like checksums), and it will be APIwise confusing if all those options
are ignored at that layer.

I tried various refactorings, and I think at least 3 or 4 class names.
The first refactoring consisted in emulating something like
OnMediaLocation but lighter, however, changing the Pathname to a new class:
- makes the interface inconsistent as lot of methods like "isAttached"
or "localPath" still take paths, and they don't need options
- If we decide to keep the old methods, the API grows exponentially

So, at the end, I ended with adding a MediaOptions class, which can
carry the metadata, and anything added later. This options parameter is
passed in addition to the Pathname, and it defaults to a empty options,
so the API stays the same (source compatible).

MediaSetAccess needs to expose these options. However, as MediaSetAccess
main responsability is workflow handling, it already got a
ProvideFileOptions on their methods which carry workflow specific
options (like non-interactive flag). Therefore while thinking where to
have those options, I kind of realized these options fit in
OnMediaLocation, so I added OnMediaLocation::mediaOptions(). That would
keep the APIs very similar, but adding some more power.

So in summary, my current proposal is:

- MediaManager:: methods and down to MediaHandler:: get an additional
parameter media::MediaOptions, which carry the metadata.
- OnMediaLocation carries a media::MediaOptions too.
(yes, I have a patch :-) )

One thing I don't have clear is how to expose the mediaOptions() from
OnMediaLocation. If I just create setter and getter, then it would be
exposed by copy or const ref. Would it make sense for mediaOptions() to
return a non-const ref so one could set the options directly (
loc.mediaOptions().addMetadata(foo,bar) ), or would it be better to wrap
the MediaOptions methods in OnMediaLocation and exposing the object as
const ref?

Comments welcome. Is ok to continue in this direction?
Thanks!

[1]: http://websvn.kde.org/trunk/KDE/kdelibs/kio/DESIGN.metadata?view=markup
-- 
To unsubscribe, e-mail: zypp-devel+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: zypp-devel+help@xxxxxxxxxxxx