blob: 13edfb8423e56ff3889cb634d2537ae1f088cd3f (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
|
TODO file:
----------
SPEEDUP fixes:
1. SPEED: Cache the object info for all items on the device.
Right now, ptp_getobjectinfo() is called repeatedly on the same
objects during startup, track listing, file listing, playlist listing,
album listing and whatever we implement tomorrow. A lot of useless
communication can be saved by cacheing this info. Notice that this
needs to be updated whenever flush_handles() is called too.
2. SPEED: Cache the supported object properties at first read/startup.
then use the cache to check for supported props instead of calling
out to PTP with ptp_mtp_getobjectpropssupported() every time.
The cache would be an array of size params->deviceinfo.ImageFormats_len
with a list for each format of the properties it will support. Notice
that this needs to be updated whenever flush_handles() is called too.
3. SPEED: Cache track metadata, file metadata etc, perhaps this is not
desirable since the application using libmtp will do this anyway.
(libgphoto2 does it, see http://svn.sourceforge.net/viewvc/gphoto/trunk/libgphoto2/camlibs/ptp2/library.c?r1=9491&r2=9590)
4. SPEED: Whenever we add an object (file, track, playlist...) we
should only need to update the cache with relevant data. Atleast for
speed caches 1 and 2 above.
FEATURE fixes:
1. FEATURE: Make abstract playlists really become size -1 when created as
the ones created on the device instead of the current 1 byte size.
(Is this possible using enhanced commands? See TODO remarks in
the create_abstract_entity() function)
2. FEATURE: Support playback and volume setting on devices that have it.
(I don't have one that does - Linus.)
3. FEATURE: Support relevant events. MTP devices seen in existance provide
events for "object added" and "object deleted". These should result in
atleast a call to the flus_handles() function.
4. FEATURE: Have libmtp optionally create a folder hierarchy such as
/Album/Artist/Song.mp3 on the device. Currently it'll only put songs
into some /Music or /My Music folder if one exists.
5. FEATURE: Integrate libmtp with HAL / D-Bus so applications can dynamically
know when a device has been plugged in or removed. Need a mechanism to
connect a specific hal UDI.
6. FEATURE: Mechanism to retrieve the DevIcon.fil (Windows ICO format) and
DevLogo.fil (PNG Format) images from the device (if available). Convert
DevIcon.fil to something usable (PNG)?
(Does this belong directly in libmtp or in a layer above?)
9. FEATURE: Shared device access so that multiple client applications can have
an open connection to the device at the same time via a handle. For example,
it should be somehow possible to run mtp-detect at the same time as amarok or
mtpfs is connected to a device. This would require some form of resource
sharing.
THOSE ARE ALREADY DONE:
1. FEATURE: Make an API that can return several devices and let the user
choose which one to operate, not just connect to the first one...
|
