On Wednesday 10 September 2008, Philip Van Hoof wrote: > We already discussed this and you seem to have replied that only adding > ints and a bool is the right solution.
No, I only suggested adding parameters because you didn't want to hear about the proper two-layer solution because that was too much work. So I tried to find a solution that was closer to your design, but it is certainly not my preferred solution. When I presented the KDE design, I thought it was clear that I was advocating this kind of architecture. > Now, about splitting the service: > > This doesn't change the current org.freedesktop.thumbnailer.Generic > interface (I'm only talking about the interface, not the implementation) Right. > It would only require changing the interface of the specialized > thumbnailers. Instead of just "Create" without a return value, it would > have to return a key to a SHM. Yes (although we might want a fallback solution for the case where SHM is not available, like actually passing pixmap data over the wire, unless you have a better idea) > Therefore, can we continue with further specifying the Generic interface > and later fine tune the specialized thumbnailer's interface? Hmm, ok, although I fear "later" is "never" in this kind of sentence :-) For anything to work you need both interfaces. > If people really think there's sanity in starting two different > specifications: one for generic resizing (and for playing the role of > the plugin interface for the thumbnailer infrastructure), and one for > generic thumbnailing (consuming the generic resizing spec to write to > the cache as specified by thumbnail-spec), then I *am* all for it. Me too (except that I still don't like the term "resizing" -- making an image that shows the first few lines of a text file is not "resizing" that text file...). I can only suggest "preview" as a better term, but I'm open to suggestions :) > > Not at all, you're the one doing that! > > I presented a design with two layers: > > * upper layer: thumbnail-spec handling > > * the layer below: data-to-image previewing > > No, you presented a design with two ints and a bool. I laid out the two > layer design ... I suggest to re-read the email where I presented the KDE design ;-) > but it doesn't matter. Let's continue. Yes. > > Can we please stick to the problem at hand instead of deriving into > > nonsense? > Relax, rhetoric is fun sometimes. It wakes people up. Sorry, I don't find rhetoric fun - I am under stress from tight deadlines to hold and I'm trying to minimize the time I spend on this (longer than I would wish, but now useful again it seems) discussion. > Obviously I didn't intent to say that your proposal is indeed like a > Universe class. I just wanted to point out that if we indeed want what > you require, that we need to do it multi-layer instead of "just add two > ints and a bool". OK. See, explicit sentences are better understood than rethoric. > I'm first going to further test, fine tune and continue with the > org.freedesktop.thumbnailer.Generic interface, and I will rethink the > org.freedesktop.thumbnailer.Thumbnailer interface for specialized > tbumbnailers. > > If the SHM proposal of yours is too difficult for average thumbnailer > coders to implement, then we'll have to find proper solutions to reduce > that complexity. Right. What we do in kio_thumbnail is that the SHM stuff is handled by the generic code, while the mimetype-specific plugins only have to create an image (in memory) from a given file. In terms of your design I think this would mean a generic previewer :-) So, generic thumbnailer --> generic previewer --> specialized previewer. (--> means "uses"). And both generic thumbnailer and generic previewer provide a standard dbus interface, so it's possible for applications to access either one directly. Specialized previewers don't have to be separate processes (ideally it's rather an in-process plugin for the generic previewer), but can be. > For example: > > How do you support writing a thumbnailer that wants to fork(); execv() a > ImageMagick binary like "convert"? You make it write in /tmp, and read > in the entire imagine into a SHM? > > Because that's a lot less efficient than how a current specialized > thumbnailer would be: the requirement to read the file into SHM is > implicit in this multi-layer proposal, for such implementations of > resizers (or thumbnailers). Right. Both layers of communication (specialized previewer --> generic previewer and generic previewer -> generic thumbnailer) have to support multiple communication mechanisms, to avoid this problem. * passing the pointer (if same process, which is the ideal solution for specialized previewers...) * SHM * path to a file * passing pixels (maybe we can do without this one, if we use tempfiles, with always the problem of "who is deleting the tempfile"). -- David Faure, [EMAIL PROTECTED], sponsored by Trolltech to work on KDE, Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org). _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
