[Playlist] Re: XSPF support in Amarok

[Sebastian Pipping]

Jeff Mitchell wrote:
> I looked at libSpiff a while back.  It seems to be overly complex and quite
> limited.

---------------------------------------------------------------------
In what way is libSpiff limited?

To name a few libSpiff ...
* can parse XSPF from a file
* can parse XSPF from a continuous block of memory
* can parse XSPF from chunks of memory
* is low on memory usage since it's using a streaming parser
* has Unicode support
* has full XML namspace support
* has full XSPF extention support

libSpiff is rather flexible to fit in any application,
which is why some complexity was needed. I think libSpiff
is still quite simple to use though and there are code
examples shipped with it as well.

You could have a look at the current API documentation
to check if you still see any issues in the latest release.
The API documentation is available online at [1].
---------------------------------------------------------------------



> Many of the XSPF elements didn't seem to be accessible unless you
> use ProjectOptusBlahBlah classes.  Even then some of them didn't seem to be
> accessible.
>
> Unless I'm misunderstanding something, I think it's telling that there needed
> to be a Project Opus extension to libSpiff to enable it to access metadata
> that's defined in XSPF in the first place. Which also gets my hackles up a
> bit, as I don't quite understand why a public and open library like libSpiff
> has huge amounts of name-branded code, with default strings pointing to the
> site, regardless of whether they wrote it or not.

---------------------------------------------------------------------
The ProjectOpus code is an example of how to write an
XSPF extension handler. It is not needed for the core libSpiff
functionality. Let me assure you this is in no way a ProjectOpus
advertisement campaign. Any non-extension information can be read
directly out of the SpiffTrack and SpiffProps classes.
---------------------------------------------------------------------



> Finally -- if XSPF is hugely dependent on whitespacing, something is wrong
> with the standard.  Elements and values in XML shouldn't matter whether you
> indent a line with two spaces or four or even no indentation at all, and
> values of elements should either be nested in <tags></tags> where
> whitespacing inside the tag is kept, or should be defined as="quoted
> properties".

---------------------------------------------------------------------
No. That "problem" comes from XML, not XSPF.
For example in any XML-based language an element with content
of type anyURI [2] has to be processed with the collapse method [3]
while other elements require any whitepsace to be preserved.
An XML parser cannot know how to handle whitespace without knowing
what type is expected at a certain point and therefore has to
pass any whitespace to the layer above, which in this case is libSpiff.
I wrote a summary of whitespace handling from the view of XSPF at [4].

So yes, maybe XML should have done that differently but that's how it is.
---------------------------------------------------------------------



> So so far, I'm in agreement that import and export of playlists in XSPF is a
> fine idea.  I am in no way seeing the reason to use libSpiff for it.

---------------------------------------------------------------------
Please see messages up in this thread for a list of reasons.



Sebastian


[1] http://libspiff.sourceforge.net/doc/html/
[2] http://www.w3.org/TR/xmlschema-2/#anyURI
[3] http://www.w3.org/TR/xmlschema-2/#rf-whiteSpace
[4] http://wiki.xiph.org/index.php/XSPF_v1_Notes_and_Errata#Whitespace