The XML… I never even though about that 😉
Good idea… from the XML, there’s one folder-key and children have a persistent ID of the parent listed. So on protocol level, there’s imho just two more fields, one flagging it as a folder, and one on the children naming the parents persistent ID.
But from what I could see with the help of my protocol debugger, mt-daapd does not yet support persistent IDs. You would need a dmap.persistentid (mper) with each container, and that should really be persistent. So I guess on /server-info, you should also a dmap.supportspersistentids and set it to true (btw why are dmap.supportsindex and dmap.supportsbrowse set to false?).
But maybe if dmap.supportspersistentids is false, it will work with normal IDs (seems you go well without persistent IDs so far)… well, from a /content-codes dump I found dmap.parentcontainerid (mpco) which probably is the field on the children to transmit. And the field to transmit whether it’a folder or not could be dmap.haschildcontainers (f??ch)… not sure why my dump has a special char on second position there, I don’t even see this field in my iTunes 6.0.1 dump, but it’s the only one I could thing of… so we need to find it!
Well now that there’s enough confusion on the protocol side, back to the mt-daapd db/user side. The playlists database probably needs a flag “isfolder” and an integer field pointing to the parent playlist or root (same as what velociped said, just that an integer pointing to the parent ID is more safe than a string pointing to its name which could change). On the user interface, this would be two things, one checkbox, and pulldown showing the folder structure (to allow the user to select the root). And, since I’ve seen in the XML that the items are stored along with the folder as well, if you want it very comfortable you could add another boolean allowing the admin to set up whether a folder should show the contents of all contained playlists (in that case just OR bracketed sql statements I guess) or not. Maybe contrary to the original, folders could also have their own playlists, but that’s something that can only be tried.
@eddieb: but writing the same code for both the old stable and the nightles would 1. make the stable unstable/nightly, and cost double the time with half of it discarded soo after 😉