TODO

   1 TODO file:
   2 ----------
   3
   4 COMPATIBILITY fixes:
   5
   6 1. COMPATIBILITY: dual-mode devices, i.e. devices exposing both an MTP
   7   and a USB Mass Storage Device Class (flashdrive) interface are and
   8   have always been problematic. We must find a way to get this to work,
   9   eventually. The problem is that the in-kernel mass storage driver hogs
  10   the device before the MTP mode gets a chance of being used, whereas
  11   the Windows kernel driver apparently does it the other way around,
  12   trying the MTP mode first and then not fall back on mass storage if
  13   MTP is available. (For some more explanations se src/libusb-glue.h.)
  14   This may involve kernel modifications. Perhaps it is only necessary
  15   to tweak the udev config not to load USB mass storage support for
  16   these devices. Dunno.
  17
  18 2. COMPATIBILITY: several devices tend to "hang" after disconnect,
  19   needing to be unplugged and replugged before they can be used again.
  20   We don't know why, it may be related to low-level USB behaviour that
  21   is not exposed in the logs we read. On some devices it appear that
  22   avoiding to release the USB interface after closing the PTP/MTP
  23   session solves this, and might be a hint at how the Windows MTP stack
  24   works: perhaps the Windows MTP daemon grabs the interface once the
  25   device is plugged in, created a session and NEVER release it.
  26   Thus only unplug or shutdown ends the session. This behaviour can be
  27   emulated (sort of) by DEVICE_FLAG_NO_RELEASE_INTERFACE which will
  28   make the device not release the USB low-level interface, though it'll
  29   still close the session. But is it really desireable to have
  30   as default? Not unless we run an MTP daemon as well, probably, and
  31   the behaviour is questionable from an USB interoperability point
  32   of view.
  33
  34
  35 SPEEDUP fixes:
  36
  37   None known. libmtp is fast :-)
  38
  39
  40 FEATURE fixes:
  41
  42 1. FEATURE: Support playback and volume setting on devices that have it.
  43   (I don't have one that does - Linus.)
  44
  45 2. FEATURE: Support relevant events. MTP devices seen in existance provide
  46   events for "object added" and "object deleted". These should result in
  47   atleast a call to the cache update function.
  48
  49 3. FEATURE: Mechanism to retrieve the device icon device property, else if not
  50   present, look for DevIcon.fil (Windows ICO format) and
  51   DevLogo.fil (PNG Format) images from the device (if available).
  52
  53 4. FEATURE: Shared device access so that multiple client applications can have
  54   an open connection to the device at the same time via a handle. For example,
  55   it should be somehow possible to run mtp-detect at the same time as amarok or
  56   mtpfs is connected to a device. This would require some form of resource
  57   sharing, discussions have centered on a D-Bus based connection arbiter
  58   daemon.
  59
  60 5. FEATURE: Implement an OpenSync backend for devices which have
  61   calendaring, contact etc support. http://opensync.org/
  62
  63
  64 THOSE ARE ALREADY DONE:
  65
  66 1. FEATURE: Make an API that can return several devices and let the user
  67   choose which one to operate, not just connect to the first one...
  68
  69 2. SPEED: Cache the object info for all items on the device.
  70   Right now, ptp_getobjectinfo() is called repeatedly on the same
  71   objects during startup, track listing, file listing, playlist listing,
  72   album listing and whatever we implement tomorrow. A lot of useless
  73   communication can be saved by cacheing this info. Notice that this
  74   needs to be updated whenever flush_handles() is called too.
  75   (This came from libgphoto2 implementing it!)
  76
  77 3. SPEED: Cache track metadata, file metadata etc in params->proplist.
  78
  79 4. SPEED: Whenever we add an object (file, track, playlist...) we
  80   should only need to update the cache with relevant data. Atleast for
  81   speedup caches.
  82
  83 5. COMPATIBILITY: account for different step sizes and intervals on some
  84   numeric properties we set, make the functions round off when possible.
  85
  86 6. SPEED: Cache the supported object properties at first read/startup.
  87   then use the cache to check for supported props instead of calling
  88   out to PTP with ptp_mtp_getobjectpropssupported() every time.
  89   The cache would be an array of size params->deviceinfo.ImageFormats_len
  90   with a list for each format of the properties it will support. Notice
  91   that this needs to be updated whenever flush_handles() is called too.
  92   THIS HAS BEEN DISCARDED, TERO IMPLEMENTED IT BUT IT DOESN'T SEEM TO
  93   YIELD MUCH.
  94
  95 7. FEATURE: Make abstract playlists really become size -1 when created as
  96   the ones created on the device instead of the current 1 byte size.
  97   (Is this possible using enhanced commands? See TODO remarks in
  98   the create_abstract_entity() function)
  99
 100 8. FEATURE: Integrate libmtp with HAL / D-Bus so applications can dynamically
 101   know when a device has been plugged in or removed. Need a mechanism to
 102   connect a specific hal UDI.
 103
 104 9. SPEEDUP: The recursive function that builds the folder tree is
 105   O(n^2)! Atleast remove all non-folders (PTP associations) from the
 106   list before we start sorting and building that tree. We walk the
 107   entire list for each group of siblings right now!
 108
 109 10. FEATURE: program to autoprobe device interfaces on connection.
 110
 111 11. FEATURE: accomodate Googles uncached device needs.
 112
 113 12. FEATURE: rudimentary event interface.