On Mo, 2011-01-17 at 04:39 +0000, [email protected] wrote:
> >Permissions
> >===========
[/dev/gadget read/write access]
> This can be done by writing a udev script where you can set the
> required permissions, add the files to a group, etc.
That looks doable. A minor complication is that the endpoints won't have
the right permissions immediately, so we need to retry for a while
before they can be opened.
So do we agree that running msyncd as group "sync", with /dev/gadget
being read/write for root and group "sync" is the way to go?
> >Starting the MTP server plugin
> >==============================
> >
> >mtp.xml specifies:
> ><profile name="mtp" type="server" >
> > <key name="usb_transport" value="true"/> </profile>
> >
> >Under which circumstances will that server be activated right
> >now in MeeGo's msyncd? If I read the buteo-syncfw code
> >correctly, it would be activated if USB gets connected, which
> >in turn is detected if usbmoded support is enabled - which as
> >far as I know, is not the case in MeeGo because usbmoded is
> >not in MeeGo.
>
> Yes, usb_moded is not in meego, but I hope that doesn't mean that USB
> connectivity can't be determined.
If I read it right, the source code implies that USB is always
considered "off" at the moment. msyncd/TransportTracker.cpp sets
iTransportStates[Sync::CONNECTIVITY_USB] = false;
and never sets it to true outside of the disabled usb_moded code.
> >Would it be acceptable to create a pseudo
> >Sync::CONNECTIVITY_ALWAYS transport? A server plugin
> >specifying that in its XML config then would be activated as
> >soon as msyncd starts and remain active as long as msyncd
> >runs, and mtp.xml could be changed to use that.
>
> That's already there, but it would be pointless to load the MTP plug-in
> always.
I agree that a true usb_moded replacement would be nice, but in the
meantime I don't see an alternative to loading the plugin all the time.
How is this already there? I only see CONNECTIVITY_USB,
CONNECTIVITY_INTERNET, CONNECTIVITY_BT.
Perhaps msyncd should consider USB as "always on" if it cannot determine
the true status?
> >Paths, configuration
> >====================
> >
> >Why is /usr/share/mtp/deviceinfo.xml copied to
> >/home/user/.mtpdeviceinfo.xml? The code says that it must be
> >writable, but it did not become clear to me why the file must be
> >writable:
>
> That's because device properties can be get/set by the initiator. We
> need to store them persistently if there's a change.
Ah, okay.
> >How can the /home/user/MyDocs path be made
> >configurable? Would deviceinfo.xml be a good place?
>
> /home/user/MyDocs represents the "root" of a storage, as defined in the MTP1
> spec.
Yes, but the spec doesn't mandate what the local path has to be, does
it? I agree with Alexander, it would be nice if all the standard
freedesktop dirs could be exposed via MTP instead of forcing devices to
use a single "MyDocs" directory.
> We can have multiple storages, and each would have their own root.
I think it would be more natural to have one root which contains
multiple, independent directories.
> The root can even be an abstraction, for eg if we have a contacts
> storage. However, deviceinfo.xml would not be the right place for
> this. I agree that a storage plug-in should declare it's root, so we
> need a confguration scheme for storage plug-in's now. As of now, as
> you know, we have only one storage plug-in.
How about this idea: the root of the MTP plugin filestorage
is /etc/mtp/filestorage/root. It can be a symlink to /home/user/MyDocs
(same result as right now), or a directory with symlinks to multiple
other directories.
The advantage of a set of symlinks over any kind of config file is that
they are easier to manipulate from shell scripts (think mounting and
unmounting external media, for example).
> >What about providing access to more than one directory?
>
> Sorry, I didn't understand. Do you mean more than one root, if so
> that's possible of course via multiple MTP storages, or do you mean
> multiple directories under the root? The latter works of course,
> because everything under the root is enumeratable.
I meant the latter.
> >Are symbolic links followed? In other words, if I set up
> > ~/MyDocs/
> > Videos -> ~/Videos
> > Pictures -> ~/Pictures
> > Music -> ~/Music
> > ...
> >would that provide access also to the content of ~/Videos and
> >~/Pictures?
>
> Yes, it could be prevented by the storage though. The initiator
> wouldn't know, as the purpose of the MTP storage is to abstract the
> internals.
I still do not fully understand how symlinks are currently handled; I'll
run some experiments.
--
Best Regards
Patrick Ohly
Senior Software Engineer
Intel GmbH
Open Source Technology Center
Pützstr. 5 Phone: +49-228-2493652
53129 Bonn
Germany
_______________________________________________
MeeGo-dev mailing list
[email protected]
http://lists.meego.com/listinfo/meego-dev
