[vlc-devel] [RFC] Nth playlist rewrite

[Rafaël Carré]

Hello,
<joke>
Best Regards,
I love you,
Please accept my modest feelings,
etc etc....
</joke>

The idea had been running for a while around my mind, so I started this
evening a playlist branch in my local tree to fix the mess in
src/playlist

As you may know it was maintained by zorglub (Clément Stenac), who is
now busy with something else since quite a while now, and I more or less
took his place, fixing some more or less critical bugs (the main reason
being my heavy use of the playlist & media library with my huge music
collection).

When I joined you, zorglub was not finished yet with the playlist, and
left it in a more or less finished state.

This not finished state included : memory corruption due to the complex
handling of 2 separate trees: one with nodes, and one without (also
known as flat)

The first thing I started here is removing the flat tree, and leave the
work to display a flat playlist to other modules.
I quickly noticed that I was reverting
[ed0b72e3714ad87cb4e10b9a7239e19b9ef0724e] which reads "Merge back
branch 0.8.6-playlist-vlm to trunk."

So I would like to ask the elders : what was this for ?
- * It is envisioned that a third tree will appear: VLM, but it's not
done yet

Was it worth ? Is there some feature I fail to understand, like the
ability to manage VLM through any GUI ?

If this is the case, and nobody is coming to do the work, I'll simply
revert that branch, and statically link the inputs to the playlist, in
order to remove the input_item_subitem_added() UGLY HACK added by
pdherbemont (Pierre d'Herbemont) for the vlc-control API (carrying its
own memory corruptions).

It MAY cause some (external, aka vlc-control) API changes, and afaik
0.9.0 is already bringing changes here, so I want to have this ready for
the next release, hopefully with the help of pdherbemont

The playlist internal API is quite complex, and some stuff (a.k.a
preparsing and metadata fetching, such as album art) is badly
implemented/splitted across input and playlist.
Since I care about that last stuff too, it's an occasion to factorize it
in the right way, because I never took the time to read the whole code.

Stay cool, I'll do that on my PRIVATE tree (which I'm ready to share
with interested people) and will not merge it without your approval.

-- 
Rafaël Carré <funman at videolan.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20080315/136b7181/attachment.sig>