Re: Fixing gvfs-backend-afc for iPhone/iPod Touch access

["Martin S." <info sukimashita com>]

On Fri, 2009-07-31 at 11:43 +0100, Bastien Nocera wrote:
> On Fri, 2009-07-31 at 12:26 퍭㐱ꫭ詴낮譞:
> > Alongside that, there would be code duplication for setting the
> > display_name/icon in both a volume monitor's volume implementation and
> > in the backend's mount() callback.
> 
> The volume monitor is supposed to try and do its best. If the code isn't
> really that much different, then maybe putting the code in a separate
> file that both could share would be best.
> 
> > The gphoto2 stuff appears to partly circumvent the issue by letting the
> > monitor volume simply grab the name/icon from HAL if previously set.
> > 
> > However in some cases it additionally still determines the name with
> > "similar" code in both monitor volume creation and the backend mount().
> > 
> > This will be an issue once more complex code is added to properly handle
> > all device variants (e.g.: set correct icon fallback names like
> > phone-apple-iphone-3gs-white).
> 
> (Note that my comment about using libgudev instead of HAL still stands,
> we won't add HAL-based stuff in gvfs, but it can be lower priority)

Gladly porting to libgudev and refactoring code once the thing
"works". :)

> You'll be able to do that when the udev callout is added. See:
> http://cgit.freedesktop.org/teuf/libgpod/log/?h=devicekit
> 

Yeah, but that would make this rely on libgpod. However, it might be
really the best option to use an udev callout to set meta data for the
iPhone/iPod Touch and then retrieve that data in both backend and
monitor volume code effectively getting rid of all the icon/name
determination code and keep that in one place for any consuming app
instead.

Infact, the libgpod iphone30 branch contains an updated HAL callout
which does exactly this using libiphone...

> > So either
> > a) two mounts, backend mount is shadowed, monitor mount inherits
> > shadowed mount name/icon and whatever else
> > b) one volume, backend mount is parented to volume when monitor issues
> > the mount
> 
> It will be b) when we figure out how to do it.
> 

Superb.

> > Still there appears to be some read/write issues when testing sqlite3 db
> > creation needed for music sync (probably some seek issue).
> > Investigating...
> 
> I had problems writing files with the original gvfs code from Patrick,
> but never had a chance to debug the problem...

Yeah, me aswell, actually it didn't work (backend crashed for me) and
emulated seeking. Read/write appears to work now just that
sqlite3_exec() appears to do something that is unhandled by the backend
which needs fixing.

--- Martin s.