Re: [Rhythmbox-devel] DACP (iTunes remote) support added

["W. Michael Petullo" <mike flyn org>]

>> I've been able to send covers (using a single hard coded filename)
>> by inserting a copy of the dcap-share.c cover sending code into
>> dmap-share.c in this new stub. However, I don't understand the
>> libdmapshare code enough to work out how to define the callback
>> function which would ask the client (in this case the Rhythmbox
>> plugin) to supply the appropriate filename.
 
> Can you send us the code you are working on? Or a branch somewhere? So we
> can help you out.
> It should be trivial to add the callback, but that would make an API break,
> so that is Michael's call.

I don't want to break the API right now. We just got over the last
libdmapsharing API mess. However, an API addition that does not break
backwards compatibility might be acceptable.

As Alexandre said, it would help us if you made your code available as
you worked. Can you submit something to GNOME Bugzilla? Or create a
Git repository?

>> It would then make sense to make the code which takes the
>> cover filename and turns this into the soup message into a
>> shared function. Note that when HAVE_GDKPIXBUF is false,
>> I think it would make sense to check the file really is a PNG
>> (and not JPEG) before sending it to the remote client. This
>> could be as trivial as checking the filename extension (since
>> this is the branch when we don't have the graphics library).

Checking the file extension in unquestionably out. There is not required
mapping between file extension and file type in Unix.

But, I have already stated that in the case of no gdk-pixbuf, it is
acceptable to me that libdmapsharing may assume that the data is PNG. I
previously stated:

> We decided on the compromise that gdk-pixbuf would be an optional
> dependency for libdmapsharing. Everything needs to work without
> gdk-pixbuf, with the exception of things like scaling and converting
> images (everything can work without gdk-pixbuf, as long as additional
> constraints are placed on how the images are stored, i.e., small and in
> PNG). This is similar to how libdmapsharing uses GStreamer. Everything
> works without it, except transcoding. As long as media is stored in a
> format supported by the clients, nothing is lost. I would like things
> to continue in this manner for the reasons noted previously.

-- 
Mike

:wq