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

[Peter <rhythmbox-devel maubp freeserve co uk>]

On Thu, Oct 28, 2010 at 9:30 PM, W. Michael Petullo <mike flyn org> wrote:
>
>>> 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?

Sure - when I'm back hacking at the code I'll sort that out.

>>> 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.

I know that, but I wasn't sure there was an inexpensive way
to check for PNG format without a library dependency - can
we just read the first few bytes as Alex suggests?

> 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 think that is unwise.

If I am writing a tool using libdmapsharing I have no way to
know if it was compiled with or without gdk-pixbuf (do I?)
but in one case I can send PNG or JPEG files to it, but in
the later you only expect PNG files (as things stand).

The DACP remote expects PNG, and passing JPEG or some
other format might cause trouble. A simple check in the non
gdk-pixbuf code branch can prevent this (tell the remote we
have no cover rather than sending non-PNG data).

Peter