<div class="gmail_quote">On Wed, Jun 9, 2010 at 9:09 PM, Jakob Leben <span dir="ltr"><<a href="mailto:jakob.leben@gmail.com">jakob.leben@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im"><div class="gmail_quote">On Tue, Jun 8, 2010 at 6:05 PM, Jakob Leben <span dir="ltr"><<a href="mailto:jakob.leben@gmail.com" target="_blank">jakob.leben@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

<div>Since we would have SD item trees composed of sd_node_t, we'd no longer need to use SD through playlist. Instead, playlist would not be a client of SD anymore, but all the former clients of playlist's SD support should become immediate clients of SD.</div>

</blockquote></div><br></div>Well, now I think that it would be best to keep the playlist-SD bridge (thus having a copy of sd_node_t hierarchy in the playlist), instead of the big amount of work needed for clients of SD in case of removing the bridge.<br>
</blockquote><div><br> An even better approach without item hierarchy duplication is probably to separate playlist_item_t interface from playlist_t interface, extend playlist_item_t with reference counting and SD-related fields and use it for SD as well. Thus a SD module would control directly a tree of playlist_item_t, which would at the same time be a child of playlist's root node.<br>
<br>And I think we would profit a lot by having proper garbage collection for playlist items anyway!<br></div></div>