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@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org