Re: [Libmtp-discuss] Album and Playlist suggestions

[Linus W. <lin...@gm...>]

2008/2/26, Ali Shah <ca...@gm...>:

> I would like to suggest some policies regarding the way we handle the
> derived file types, Album and Playlist.
> I propose that LIBMTP_Album_t and LIBMTP_Playlist_t both should have a field
> for their parent directory rather than  supply a parent directory at the
> time of creation.

Why not both...? You have this new field and you supply it at creation
time also (as we do today).

> The reason being an LIBMTP_Album_t is displayed as a file on my device (and
> i expect most other devices). This means that when we create new albums, a
> new file must be created to represent this via LIBMTP_new_file() as libmtp
> does not implicitly create an encapsulated file for every new derived type
> we create on the device (eg track, album or playlist).

I don't quite follow this. We create objects for albums and playlists alike,
they are no different from tracks or files or folders. They should turn up in
file listings with "mtp-files" with apropriate suffixes afterwards.

That is I *DO* think we create an "encapsulated file" (whatever that is, this
is not PTP/MTP terminology).

> This way when a new album is created on the device with this field set to 0,

You mean the parent_id field?

> it can be updated to the corresponding default destination's ID.

No it can't. After some tiresome testing we concluded that you cannot
update parent_id on objects on any devices on the market. You have to
specify parent ID when you create any object, no matter if it's a file,
track, playlist etc. It cannot be changed afterwards.

> This helps
> us GUI makers keep different views of the underlying file/album/playlist
> abstraction in sync with the device, since we can tell who the parent folder
> is for the given album and look it up in a hash table etc.

Yeah it's still good to have the parent_id I guess so we could add that
(interested in writing a patch?)

But you will never be able to move tracks or filelists etc around in
folders on the device in any simple way. The devices are not designed
to handle this.

> Sometimes I wonder if the policy should be that when a new derived file type
> is created on the device, libmtp should create a file as well.

It does. It creates an object, e.g. a playlist "foo" is created as an object
with filename set to "foo.zpl".

> The reason is
> simple: if one were to disconnect the device, and reconnect it, one would
> see two duplicate object IDs. One of which is a file and the other would be
> the derived file type we created, perhaps this could be returned via a
> double pointer from the LIBMTP_Create_* functions.

Uh... you should only create albums, playlists and albums with the
LIBMTP_Create_Album() etc functions, not by abusing the file API.

Perhaps I don't quite understand this... please correct me. :-/

Linus