_             _ _     _   
	 _ __ | | __ _ _   _| (_)___| |_ 
	| '_ \| |/ _` | | | | | / __| __|
	| |_) | | (_| | |_| | | \__ \ |_ 
	| .__/|_|\__,_|\__, |_|_|___/\__|
	|_|            |___/             

General principles (Tree playlist)
---------------------------------------------

* tree playlist
* several "views" that are several tree pointing to playlist items

* views are 
    - "simple" view for manually added items
    - category view
	- Service discovery ( new capability ) 
 	- imported playlists
	- Web radios / TV
		( provide a list of those with vlc ? could be interesting
		  but would require maintenance of the list )
	- CD Audio
	    for that the dream would be a "prober" to get the tracks as items
	    and a callback system to update on new cd insertion
 	    (at least for Win and Mac)
        - ... ?
    - "all items" flat view
    - views for items sorted and grouped by meta information ( author,album,...)

Nécessités
----------

* All must continue working without it
   (if we don't want to be bothered, if the interface does not implement, ..)
     -> how to do for service discovery ?
     -> "Débrayabilité" complète ? ( - de mémoire, ... )

Finding parents
--------------

* an item can have several parents ( one in each view )
* but a node can too as an item can change to a node

so

* either we don't store the parents and search each time
		-- CPU
* either we store an array [view_id => p_parent ]
	more memory needed but less CPU


Misc Questions
---------------

* Saving the ML
   -> Not good for all (can sometimes be bad)
        (flag b_save ?)
   -> automatic when quitting
   -> could be forced

* do we put all played/playlist items in the ML ?
	IMO, no (very gruik)
	We could have a special category "Last 10 played items"	
	(this one should be saved of course)

* Items can change to nodes
	- playlists
	- directories ( new "Tree" mode, subdirectories are added as nodes)

* For playlists
	Recursion ( automatically )?
	  -> Hard, how to detect playlist-in-playlist ?
	  -> What to do when reading an M3U with vlc ?
		We should add it to the ML, quite hard
		Possible if we have p_parent (NULL if we did not use the ML)
	  Another possibility: we only make recursion based on extension,
	  and don't bother about the others, they won't appear in the ML
  - Save all
  - Export as playlist (flat)


Modules
-------

Playlists :
- - - - - -

Needed to parse playlists. We could keep the current structure, as a
demux. This is good because we have all features/abstractions provided
by input. But we shouldn't add directly items to playlist (maybe use
modes, ...)

Better:

A new type of modules "playlist-parser" that "take" a char * and give
back( how ? using p_private ? ) playlist_item_t **

These modules can be called from the core ( ImportPlaylist,
playlist_Load) or from a playlist demuxer (that whould become a simple
wrapper)

It's a bit more complex and slow (bah) and we loose stream_... (well, we
can live without them ;) ) but it's much cleaner.

problem : doing this, ImportPlaylist and playlist_Load can only take
a file and not anything as we can with the access/demux system (for HTTP
playlist for examples).

Well, it remains a very specific case.


Another way to do this is to create a separate input thread to parse the playlist

Service discovery
- - - - - - - - -
We should be able to quit those modules.

We might try to impement this with a button in the intf
"Enable SAP", "Restart SAP", ...

how to find the right one ?

Do we remove the category when leaving ?

Misc
----

* playlist_AddItems( p_playlist, pp_items, i_items ) 
  to add several items at once without triggering intf-change each-time
  interest: much faster beause we still rebuild the playlist
  (by the way :
	we shouldn't rebuild the playlist if the item is added at the end
	and we should stop find/release the playlist at each item in wx !!)

* Simplify the playlist engine (src/playlist/playlist.c) which has become terribly complex and buggy
	- clean callback management
	- clean modes management
	- manage "requests" asynchronously ( we put a b_request flag )
	`	(lag problem ) ?
	
* Re-write sap (where are we with livedotcom now? ) and make it a service discovery module

* make SLP a service discovery module  and have a proper naming scheme