devel update / 05.26.05

i've been dragging my feet and doing other things, here's a beta build of plext/xspf..

http://users.mnemonic.net/bay/plext/plextxspf.zip

the previous .dll links are dead, this is the only valid link.

remote xspf should work (http fetches)
this includes open location and internal to a playlist entry
plext compiles a name of supported types and avoids fetching mimes of known extensions (http:// urls)

ive yet to write the code surrounding file:// uris nor proper file:// generation in saved xspfs with local (file://) content. this will be fixed in next build..

bug reports welcomed.

devel update / 05.12.05

plext's http handling works now, as tested outside and inside the in_plext plugin this morning at 5:xx am. in conjunction with pl_xspf, a remote fetch of an xspf from webjay was sucessful.

lets hear it for progress.

devel update / 05.11.05

from my posting to shrimpies:

theres some hackish code to be replaced, that and getting the remote
stuff working.. but at least plext is coming through.

http://users.mnemonic.net/bay/plext/in_plext.dll
http://users.mnemonic.net/bay/plext/pl_xspf.dll

in_plext.dll - main dll
pl_xspf.dll - xspf support

note, that you can only open local xspfs with pl_xspf.dll

note also that all saving of any playlist type (m3u,pls,xspf) isnt
gonna write anything as long as in_plext.dll is loaded.

opening should still work since i don't handle that for m3u or pls.
it's the saving overload that i have nothing happening.

note: this means if you have firefox sending xspf's from webjay to
winamp with this they should play.

note: this means that a playlist that has an http:// xspf will not
play that xspf location in the playlist

note: this means that if you type in a location of http:// xspf will not play

devel update / 05.05.05

more plext code has been filled in, mostly in tweaking for plext::xspf. i smell a release in a week or so. no fake.