Ticket #1438 (Closed: fixed)

There is a problem - I can preaccess all audioClips in hierarchy of embedded playlists, but I can't generally access the embedded playlist themselves, because it may not be separately stored in the storageServer and then it may not exist as separately accessible object. Do you mean I should only reflect hierarchy of embedded playlists in the 'files' field istead of plain array of audioClips URLs? - i.e. make this field hierarchical? If there is only nested real playlist (playlist stored in the storageServer): <playlistElement id="..." relativeOffset="..."> <playlist id="real_playlist_ID" playlength="..." title="..." /> </playlistElement> it's OK - I can preaccess it as well. BTW. I will be on-line on IM tomorrow (Mon 5.Sep) as possible.

I'm not sure if I understand what you mean. let's take the following use case, of opening an embedded playlist via XML-RPC. suppose we have the following structure: playlist1 |-- clip1.1 |-- playlist1.2 | |-- clip2.1 | `-- clip2.2 |-- clip1.3 `-- clip1.4 with the 'old' XML-RPC API, one would make the following calls: xr_accessPlaylist(playlist1) then parse the XML returned, then call: xr_accessRawAudioData(clip1.1) xr_accessPlaylist(playlist1.2) (parse again) xr_accessRawAudioData(clip2.1) xr_accessRawAudioData(clip2.2) xr_accessRawAudioData(clip1.3) xr_accessRawAudioData(clip1.4) instead of all these calls, we would need a single call, that returns all information at once, that was returned above in separate calls. but this is quite easy: just create an tree structure in the return value, and pass on all information that would be returned with the separate calls. for example, currently xr_accessPlaylist returns a structure like: {url, token, checksum} and xr_accessRawAudioData returns a structure like: {url, token} (according to the documentation.. no checksum?) now, it could return: {plalyist1.url, playlist1.token, playlist1.checksum, { {clip1.1.url, clip1.1.token}, {playlist1.2.url, playlist1.2.token, playlist1.2.checksum, {clip2.1.url, clip2.1.token}, {clip2.2.url, clip2.2.token} }, {clip1.3.url, clip1.3.token}, {clip1.4.url, clip1.4.token}, } note that it's the same information returned as before, but only in one go...

I can use the return structure you described - it's clear and pretty, I'm going to implement it immediately, but there remains problem with embedded playlists. Terminology as I used - correct me, please, if I'm wrong: 1) nested playlist - playlist included in playlistElement, but without own inline content - its content is stored in storageServer under its id (its id is not equal with parent playlist id) - it's something as "playlist symlink" ;) 2) embedded playlist - included in playlistElement too - have inline content (own playlistElement tags) - <b>shouldn't be stored in storageServer under its own ID, because it would be redundant definition of this playlist</b> IMO we shouldn't use embedded playlists - there is problem with redundance or difficult accessibility. Nested playlists are IMO better - and we can call them "embedded" ;)

I'm not sure about inline playlists myself, Ferenc will clear this issue up shortly...

Return structure implemented now: {plalyist1.url, playlist1.token, playlist1.checksum, { {clip1.1.url, clip1.1.token}, {playlist1.2.url, playlist1.2.token, playlist1.2.checksum, {clip2.1.url, clip2.1.token}, {clip2.2.url, clip2.2.token} }.content, {clip1.3.url, clip1.3.token}, {clip1.4.url, clip1.4.token}, }.content } The field 'files' have been renamed to 'content' field - 'files' was not suitable for this type of structure. The current implementation handle inline playlists too, but returns null in url,token etc. fields for inline playlist.

thanks... I'm asking Ferenc on his view on these inlined playlists...

Yes, with the current structure it is theoretically possible to upload a playlist with an embedded playlist which is not in the storageServer. But the GUI does not allow this, so (barring some strange bug) it should never happen. The current structure is highly redundant and stupid, and should be changed as you suggest, to a symlink-type system. The question is: do we need to do this today, or can it wait for release 1.0.1?

1.0.1

I incorporated the changes to be used by the storage client. but we have to look through this protocol in detail, as currently it's highly redundant and ugly as well :(