libSpiff 0.8.4 released

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

libSpiff 0.8.4 released

Sebastian Pipping
This release mainly introduces support for the xml:base attribute.
If you work with XSPF files not created by libSpiff, updating is
highly recommended. This release is both source- and binary-compatible.


Download:
http://sourceforge.net/project/showfiles.php?group_id=176018

Changelog:
http://sourceforge.net/project/shownotes.php?release_id=616923&group_id=176018



Sebastian

_______________________________________________
Playlist mailing list
[hidden email]
http://lists.musicbrainz.org/mailman/listinfo/playlist
Reply | Threaded
Open this post in threaded view
|

Re: libSpiff 0.8.4 released

M@d Man
Hello,

Sebastian Pipping schrieb:
> This release mainly introduces support for the xml:base attribute.
> If you work with XSPF files not created by libSpiff, updating is
> highly recommended. This release is both source- and binary-compatible.
>  
Nice to read about the xml:base feature. I tried to update my foo_xspf
foobar2000 plugin some time ago but waited for the xml:base support. As
I now study this feature I wonder how to access the base URI in a
Spiff::SpiffReaderCallback::addTrack() function for resolving the track
locations.
I could store the base URI in the callback object, but it's only
available via setProps() after the playlist tag is read completely wich
is after every addTrack() function was called.

Or is the library going to resolve the relative URIs in future versions
itself? Since libspiff uses uriparser this could be done with the help
of the uriAddBaseUriA() function (perhaps when every isUri() is called
in SpiffReader).

Anyhow thank you for this update.

Best regards

Clemens Terasa

_______________________________________________
Playlist mailing list
[hidden email]
http://lists.musicbrainz.org/mailman/listinfo/playlist
Reply | Threaded
Open this post in threaded view
|

Re: libSpiff 0.8.4 released

Sebastian Pipping
Hello Clemens!


M@d Man wrote:
> Nice to read about the xml:base feature. I tried to update my foo_xspf
> foobar2000 plugin some time ago but waited for the xml:base support. As
> I now study this feature I wonder how to access the base URI in a
> Spiff::SpiffReaderCallback::addTrack() function for resolving the track
> locations.
> I could store the base URI in the callback object, but it's only
> available via setProps() after the playlist tag is read completely wich
> is after every addTrack() function was called.

I see, that sucks. Sorry, I didn't think about that before.
The SpiffProps instance cannot be fired earlier because there
could be data after the <trackList> element:

    <playlist version="1" xmlns="http://xspf.org/ns/0/">
      <trackList />
      <location>foo</location>
    </playlist>

I think that means we either have to (A) extend SpiffReaderCallback
or (B) give the SpiffTracks access to xml:base somehow.


For (A) I can think of two different ugly solutions:

    // (A.1) "The binary-compatibility breaker"
    class SpiffReaderCallback {
    private:
      virtual void addTrack(SpiffTrack * track);
      virtual void setProps(SpiffProps * props);
      virtual void setXmlBase(const XML_Char * xmlBase);
    };


    // (A.2) "Behind our backs"
    class SpiffReaderCallback {
    private:
      // These two can now call getXmlBase() whenever
      // they like and resolve URIs themselves.
      // setXmlBase() is called by the SpiffReader
      // before the first call to one of addTrack()
      // or setProps()
      virtual void addTrack(SpiffTrack * track);
      virtual void setProps(SpiffProps * props);
      void setXmlBase(const XML_Char * xmlBase);
    protected:
      const XML_Char * getXmlBase();
    };


For (B) it would be moving these four methods from
SpiffProps up to SpiffData which SpiffProps and SpiffTracks
both derive from:

   void giveXmlBase(const XML_Char *xmlBase, bool copy);
   void lendXmlBase(const XML_Char *xmlBase);
   XML_Char * stealXmlBase();
   const XML_Char * getXmlBase() const;

I wonder if that (= moving up a non-virtual function)
would break binary compatibility?


> Or is the library going to resolve the relative URIs in future versions
> itself? Since libspiff uses uriparser this could be done with the help
> of the uriAddBaseUriA() function (perhaps when every isUri() is called
> in SpiffReader).

I agree libSpiff could and maybe should do that. Probably the main
reason I why I have not implemented this yet is that I have not been
knowing the best way to do it.

Thoughts I have about this:

  - If libSpiff offers URI resolution it should offer this in
    addition while not hurting access to the unmodified original URI.

  - If no xml:base is given in a playlist the libSpiff user has to tell
    us the desired base URI manually. Where/how should that happen?


Do you think it would be good to duplicate functions like this?:

   // Currently present, unmodified URI
   XML_Char * stealLocation();

   // Return URI resolved with <absBaseUri> as base URI
   // absBaseUri must be (1) not NULL and (2) a valid absolute
   // URI and (3) play by the rules of XML Base's priorities
   XML_Char * stealLocation(const XML_Char * absBaseUri);


Please let me know what you think and what would work best
for you and foo_xspf. I hope we can find a solution together.

Is the code of foo_xspf available in a public repository?



Sebastian


_______________________________________________
Playlist mailing list
[hidden email]
http://lists.musicbrainz.org/mailman/listinfo/playlist
Reply | Threaded
Open this post in threaded view
|

Re: libSpiff 0.8.4 released

M@d Man
Hallo Sebastian!

Ich habe erst jetzt die Zeit gefunden Dir zu antworten. Danke für deine
Hilfestellungen. Die Lösungen gefallen mir, ich könnte aber nicht sagen
welche die "beste" ist.
Für mich wäre es die beste Möglichkeit, wenn man gar nicht auf
getXmlBase zugreifen müsste, sondern die Auflösung der relativen URIs
von libspiff übernommen würde.
Zu der Auflösung:
>   - If libSpiff offers URI resolution it should offer this in
>     addition while not hurting access to the unmodified original URI.
>  
Die Frage ist, ob man überhaupt in Lage sein sollte, an die
unveränderten URIs heranzukommen. Schließlich sollen die URIs ja gerade
nach den xml:base Vorschriften aufgelöst werden.
Ich kann mir im Moment kein Szenario vorstellen, bei dem die Auflösung
nicht sinnvoll ist, oder manuell durchgeführt werden sollte.
>   - If no xml:base is given in a playlist the libSpiff user has to tell
>     us the desired base URI manually. Where/how should that happen?
>  
Man könnte beim aufrufen des Parsers eine zusätzliche Variable
übergeben, oder aber eine neue Membervariable baseUri für den
SpiffReader einführen, die vor dem parsen gesetzt werden könnte.
Dies würde der Regel "The base URI is defined by the context of the
application." der xml:base Spezifikation entsprechen.
Die parseFile Funktion könnte außerdem den Pfad zur zu parsenden Datei
als base-URI verwenden. Dies würde der Regel "The base URI is the URI
used to retrieve the entity." der xml:base Spezifikation entsprechen.
Hierbei sellt sich ein Problem, wenn diese Datei nur eine lokale Kopie
einer entfernt verfügbaren Datei ist.

Wenn keine base-URIs angegeben werden, dann wedern die Daten einfach
relativ zurückgegeben.

>
> Do you think it would be good to duplicate functions like this?:
>
>    // Currently present, unmodified URI
>    XML_Char * stealLocation();
>
>    // Return URI resolved with <absBaseUri> as base URI
>    // absBaseUri must be (1) not NULL and (2) a valid absolute
>    // URI and (3) play by the rules of XML Base's priorities
>    XML_Char * stealLocation(const XML_Char * absBaseUri);
>  
Wie oben schon erwähnt, bin ich mir nicht sicher, ob man überhaupt an
die unaufgelösten URIs heran kommen sollte. Wenn man dies aber will, ist
es eine gute Möglichkeit sie so Aufzulösen.
> Is the code of foo_xspf available in a public repository?
>  
Ich arbeite gerade daran, den Code aufzuräumen und die Altlasten vom
Xerces-Parser zu entfernen. Ich habe ein sourceforge-Projekt gestartet,
wobei der Code noch nicht verfügbar ist. Dies sollte sich aber in den
kommenden Tagen ändern.

Clemens


_______________________________________________
Playlist mailing list
[hidden email]
http://lists.musicbrainz.org/mailman/listinfo/playlist
Reply | Threaded
Open this post in threaded view
|

Re: libSpiff 0.8.4 released

Sebastian Pipping
I think Clemens forgot to reply in English because in a second offlist
mail I supposed we both speak German natively.

I'll try to _loosely translate his mail_ below so everybody interested can
follow. I'll reply in a second mail later.

Clemens, please correct me wherever you feel I hurt your original meaning.
I'm aware translating other people's mails is a bit unusual but it will
be fun for me and feels better than asking you for it. In case it reads
like Google-translated - be sure it's not :-)



M@d Man wrote:
> Hallo Sebastian!
>
> Ich habe erst jetzt die Zeit gefunden Dir zu antworten. Danke für deine
> Hilfestellungen. Die Lösungen gefallen mir, ich könnte aber nicht sagen
> welche die "beste" ist.
> Für mich wäre es die beste Möglichkeit, wenn man gar nicht auf
> getXmlBase zugreifen müsste, sondern die Auflösung der relativen URIs
> von libspiff übernommen würde.
> Zu der Auflösung:

I didn't find time to reply before, thanks for your reply.
I like the ideas you proposed but I'm undecided which one works best.
In a way I would like best if libSpiff would do the translation for me
without having to work with getXmlBase().


>>   - If libSpiff offers URI resolution it should offer this in
>>     addition while not hurting access to the unmodified original URI.
>>  
> Die Frage ist, ob man überhaupt in Lage sein sollte, an die
> unveränderten URIs heranzukommen. Schließlich sollen die URIs ja gerade
> nach den xml:base Vorschriften aufgelöst werden.
> Ich kann mir im Moment kein Szenario vorstellen, bei dem die Auflösung
> nicht sinnvoll ist, oder manuell durchgeführt werden sollte.

I wonder if access to the original URI is needed since the have to
be resolved against xml:base anyway. I cannot think of case where
one would not want to resolve the URI or want to do it manually.


>>   - If no xml:base is given in a playlist the libSpiff user has to tell
>>     us the desired base URI manually. Where/how should that happen?
>>  
> Man könnte beim aufrufen des Parsers eine zusätzliche Variable
> übergeben, oder aber eine neue Membervariable baseUri für den
> SpiffReader einführen, die vor dem parsen gesetzt werden könnte.
> Dies würde der Regel "The base URI is defined by the context of the
> application." der xml:base Spezifikation entsprechen.
> Die parseFile Funktion könnte außerdem den Pfad zur zu parsenden Datei
> als base-URI verwenden. Dies würde der Regel "The base URI is the URI
> used to retrieve the entity." der xml:base Spezifikation entsprechen.
> Hierbei sellt sich ein Problem, wenn diese Datei nur eine lokale Kopie
> einer entfernt verfügbaren Datei ist.
>
> Wenn keine base-URIs angegeben werden, dann wedern die Daten einfach
> relativ zurückgegeben.

You could pass an additional variable when invoking the parser or
add a new member variable holding the base URI to SpiffReader
that could be set before parsing. This would be the rule
"The base URI is defined by the context of the application."
of the XML Base specification.
Also, the method parseFile could use the path of the parsed file
as Base URI. This would be thr rule "The base URI is the URI used
to retrieve the entity." of the XML Base specification. In that case
it would be a problem if the file is just a local copy of a remote
playlist.

If no base URI is given the URI are returned unresolved.


>> Do you think it would be good to duplicate functions like this?:
>>
>>    // Currently present, unmodified URI
>>    XML_Char * stealLocation();
>>
>>    // Return URI resolved with <absBaseUri> as base URI
>>    // absBaseUri must be (1) not NULL and (2) a valid absolute
>>    // URI and (3) play by the rules of XML Base's priorities
>>    XML_Char * stealLocation(const XML_Char * absBaseUri);
>>  
> Wie oben schon erwähnt, bin ich mir nicht sicher, ob man überhaupt an
> die unaufgelösten URIs heran kommen sollte. Wenn man dies aber will, ist
> es eine gute Möglichkeit sie so Aufzulösen.

As I said above I'm not sure if access to the unresolved URIs is needed.
If it should be this might be a good way to resolve them.


>> Is the code of foo_xspf available in a public repository?
>>  
> Ich arbeite gerade daran, den Code aufzuräumen und die Altlasten vom
> Xerces-Parser zu entfernen. Ich habe ein sourceforge-Projekt gestartet,
> wobei der Code noch nicht verfügbar ist. Dies sollte sich aber in den
> kommenden Tagen ändern.

I'm currently doing code cleanup and removing stuff left over from
using Xerxes for XML parsing before. I have created a project
at SourceForge but I will need a few more days before I can
check in the code.

http://sourceforge.net/projects/fooxspf



Clemens // Loose translation by Sebastian

_______________________________________________
Playlist mailing list
[hidden email]
http://lists.musicbrainz.org/mailman/listinfo/playlist
Reply | Threaded
Open this post in threaded view
|

Re: libSpiff 0.8.4 released

M@d Man
Opps, sorry, I hit the wrong button :)
Thanks, Sebastian for translating.

Clemens

_______________________________________________
Playlist mailing list
[hidden email]
http://lists.musicbrainz.org/mailman/listinfo/playlist
Reply | Threaded
Open this post in threaded view
|

Re: libSpiff 0.8.4 released

Lucas Gonze
In reply to this post by Sebastian Pipping
Sebastian Pipping wrote:
> I'll try to _loosely translate his mail_ below so everybody interested can
> follow. I'll reply in a second mail later.

Thanks for doing it.

> I wonder if access to the original URI is needed since the have to
> be resolved against xml:base anyway. I cannot think of case where
> one would not want to resolve the URI or want to do it manually.

Good point.

>>>   - If no xml:base is given in a playlist the libSpiff user has to tell
>>>     us the desired base URI manually. Where/how should that happen?

> You could pass an additional variable when invoking the parser or
> add a new member variable holding the base URI to SpiffReader
> that could be set before parsing. This would be the rule
> "The base URI is defined by the context of the application."
> of the XML Base specification.
> Also, the method parseFile could use the path of the parsed file
> as Base URI. This would be thr rule "The base URI is the URI used
> to retrieve the entity." of the XML Base specification. In that case
> it would be a problem if the file is just a local copy of a remote
> playlist.
>
> If no base URI is given the URI are returned unresolved.

I dunno.  For playlists on a local filesystem it's really useful to be
able to use relative paths.  I've seen this in the real world, e.g.
with winamp m3u support.

> http://sourceforge.net/projects/fooxspf

I'm really happy to see this, Clemens.

_______________________________________________
Playlist mailing list
[hidden email]
http://lists.musicbrainz.org/mailman/listinfo/playlist
Reply | Threaded
Open this post in threaded view
|

Re: libSpiff 0.8.4 released

Sebastian Pipping
In reply to this post by Sebastian Pipping
> I wonder if access to the original URI is needed since the have to
> be resolved against xml:base anyway. I cannot think of case where
> one would not want to resolve the URI or want to do it manually.

It might sounds a little constructed but I could imagine that this
would be useful in a context where you pre-process or slightly
modify an XSPF playlist passing through, e.g. as the spiff_strip
libSpiff example does. Other than that I just feel keeping it would
a good idea for two theoretical reasons:

  - Backward compatibility to previous libSpiff releases

  - If libSpiff's "thinking" for whatever reason is not that of
    its user, he (or she) can still get what he wants by
    working with unmodified input.


>>>    // Currently present, unmodified URI
>>>    XML_Char * stealLocation();
>>>
>>>    // Return URI resolved with <absBaseUri> as base URI
>>>    // absBaseUri must be (1) not NULL and (2) a valid absolute
>>>    // URI and (3) play by the rules of XML Base's priorities
>>>    XML_Char * stealLocation(const XML_Char * absBaseUri);
>
> As I said above I'm not sure if access to the unresolved URIs is needed.
> If it should be this might be a good way to resolve them.

Thanks for sharing your thoughts about it. I think the following is
the solution we should give a try:

- All function of Spiff{Data,Props,Track} dealing with URIs are
   given counterparts resolving against a given base URI.
   xml:base is used instead if found in the playlist.

- The xmlBase code is moved up from SpiffProps to SpiffData.
   That way absolute locations can be queried from a SpiffTrack
   inside of the SpiffReaderCallback derivative's addTrack() method
   easily. Giving this a try will show how likely this is to break
   binary compatibility. I'm quite curious actually.

Please share your personal schedule for foo_xspf with me if you have
any so I know how fast I need to be.

--------------

There is something else about foo_xspf coming to my mind today:
Will you need filename-to-URI-and-back functionality from libSpiff
or are you doing that manually already?


> I'm currently doing code cleanup and removing stuff left over from
> using Xerxes for XML parsing before. I have created a project
> at SourceForge but I will need a few more days before I can
> check in the code.
>
> http://sourceforge.net/projects/fooxspf

In case you have no preference among CVS and Subversion I recommend
to go for Subversion. Besides other benefits you will be able to
included libSpiff's code through svn:externals for instance.

Great to see you are moving to SourceForge!



Sebastian


_______________________________________________
Playlist mailing list
[hidden email]
http://lists.musicbrainz.org/mailman/listinfo/playlist