On Tue, 10 Aug 2004, Kevin Prichard wrote:

> On Tue, 10 Aug 2004, Lucas Gonze wrote:
>
>>
>> On Wed, 11 Aug 2004, kevin3prichard wrote:
>>
>>> Lucas,
>>>
>>> How is authentication done?  Basic, or something else?  I've been able
>>> to fetch a playlist with username only, just using a URL, no form
>>> fields, no password.
>>
>> Can you tell me the URL you used?  Chances are good that it wasn't
>> supposed to be restricted.
>
> http://webjay.org/api/xspf/kev/themusic
>
> could you splain which api calls need passwords and which don't?

Yup:

all POST calls need a password, and all GET calls except /api/help and
/api/xspf/username/shortname.

>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>

you fucking rock.

On Wed, 11 Aug 2004, kevin3prichard wrote:

> Here are some frutta di mi labors.
>
> 1) Look for latest upload to files section, "wjtester5.php".  This one
> works, plus it has no libcurl or xslt_* dependencies.  Track URLs seem
> to be splitting on ampersands, something to fix later.
>
> Far out!  Happy to see it working, especially as it has what I think
> and hope is a fairly narrow set of dependencies.  Although who the
> heck knows?  Maybe the array functions I'm using are too recent;
> easily removed.
>
> 2) Call for testers: Please! download the above file and copy to a
> webserver near you, one with a PHP 4.0.5 minimum installation.  Please!
> post errors and successes to the list.
>
> Comment on coding PHP for compatibility across many servers: this is a
> bit like writing client-side Javascript.  A lotta testing necessary to
> find out what works and what doesn't.  This version works on three
> servers so far.
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>

On Tue, 10 Aug 2004, Lucas Gonze wrote:

>
> On Wed, 11 Aug 2004, kevin3prichard wrote:
>
> > Lucas,
> >
> > How is authentication done?  Basic, or something else?  I've been able
> > to fetch a playlist with username only, just using a URL, no form
> > fields, no password.
>
> Can you tell me the URL you used?  Chances are good that it wasn't
> supposed to be restricted.

http://webjay.org/api/xspf/kev/themusic

could you splain which api calls need passwords and which don't?

Here are some frutta di mi labors.

1) Look for latest upload to files section, "wjtester5.php".  This one
works, plus it has no libcurl or xslt_* dependencies.  Track URLs seem
to be splitting on ampersands, something to fix later.

Far out!  Happy to see it working, especially as it has what I think
and hope is a fairly narrow set of dependencies.  Although who the
heck knows?  Maybe the array functions I'm using are too recent;
easily removed.

2) Call for testers: Please! download the above file and copy to a
webserver near you, one with a PHP 4.0.5 minimum installation.  Please!
post errors and successes to the list.

Comment on coding PHP for compatibility across many servers: this is a
bit like writing client-side Javascript.  A lotta testing necessary to
find out what works and what doesn't.  This version works on three
servers so far.

Hello,

This email message is a notification to let you know that
a file has been uploaded to the Files area of the webjay-dev
group.

   File        : /wjtester5.php
   Uploaded by : kevin3prichard <kevin3prichard@...>
   Description : working proof-of-concept, without xslt or curl dependencies. 
displays basic playlist info after user inputs username and playlist name.

You can access this file at the URL:
http://groups.yahoo.com/group/webjay-dev/files/wjtester5.php

To learn more about file sharing for your group, please visit:
http://help.yahoo.com/help/us/groups/files

Regards,

kevin3prichard <kevin3prichard@...>

On Wed, 11 Aug 2004, kevin3prichard wrote:

> Lucas,
>
> How is authentication done?  Basic, or something else?  I've been able
> to fetch a playlist with username only, just using a URL, no form
> fields, no password.

Can you tell me the URL you used?  Chances are good that it wasn't
supposed to be restricted.

Lucas,

How is authentication done?  Basic, or something else?  I've been able
to fetch a playlist with username only, just using a URL, no form
fields, no password.

kevin

Howdy all,

Over the last few days I've been experimenting with proof-of-concept
attempts under PHP.  It turns out that PHP's xslt and libcurl APIs are not
universally available.  Replacing both of them in the limited way that wj
needs them is not a major undertaking, using the built-in common APIS for
sockets and SAX-style XML parsing.

On a nerdy tangent, one concern I've had, for the future, is how to deal
with a busy site:  how to employ both TCP and HTTP keep-alive, to keep
socket connection overhead to a minimum, to benefit WJ's server(s) as well
as lowering wait time for the end-user.

Turns out that php's common API for tcp supports "persistent," aka
keep-alive, tcp connections.  Unlike Java, though, PHP doesn't have much
support for keeping server-side data alive, outside of individual session
arrays, and keeping state in a database.  There's a shared-memory API, but
like the others, it's not universally available, and it's uncertain
whether a resource handle, once stashed in a shared memory block, wouldn't
get closed automatically anyway at the end of page script execution, as so
many other resources are currently (database connections, for example.)

I was hoping for some persistent data structure in which one could store
an array of keep-alive socket connections to webjay.org.  There's nothing
really available, but I tried this hack:

# set the session ID to one global value, temporarily, to access
# persistent values shared across visitors
session_id( '--SERVER--' );
session_start();

if(!isset($_SESSION['socket'])) {
   $_SESSION['socket'] = pfsockopen( 'webjay.org', '80', $errno, $errstr,
30 );
}

fwrite( $_SESSION['socket'], "GET /api/xspf/username/shortname \
HTTP/1.0\r\nhost: webjay.org\r\nConnection: Keep-Alive\r\n\r\n" );

and so on.  Up to this point, everything works fine.  But when the next
user tries to obtain the 'socket' handle, it's no longer a resource that
fwrite likes.  I've tried putting '=&' in place of the '=' for pfsockopen,
to store the resource address, but that didn't change anything.

Dang, that would've been very handy.  I think this is why people write
server-side persistence in Perl and Java, because there's better support
for system-wide features.  If there were one thing I'd change for PHP,
that'd be it - and the ability to lock objects shared across sessions, so
you wouldn't have two processes writing to the same memory at the same
time.

Maybe there's a way to keep a script running on the server that can cache
resources like these, and serve as a transfer point or gateway.  Such a
script might be written in PHP, and run as a background command-line PHP
process, listening on a localhost socket, and caching socket connections
internally to webjay.  That's probably pushing PHP's envelope beyond
comfortable possibilities, but something to look at for the future.  (I
see there are socket listen functions in PHP, but they're labeled
"experimental."  Same thing could be accomplished with Perl and bundled as
a script with the WJ php api, so something to keep in mind for the future:
a local proxy script that caches keep-alive connections.)

Hello,

This email message is a notification to let you know that
a file has been uploaded to the Files area of the webjay-dev
group.

   File        : /xmltest.php
   Uploaded by : kevin3prichard <kevin3prichard@...>
   Description : PHP+curl+xslt proof-of-concept attempt #1

You can access this file at the URL:
http://groups.yahoo.com/group/webjay-dev/files/xmltest.php

To learn more about file sharing for your group, please visit:
http://help.yahoo.com/help/us/groups/files

Regards,

kevin3prichard <kevin3prichard@...>

On Fri, 6 Aug 2004, Lucas Gonze wrote:

> On Fri, 6 Aug 2004, Kevin Prichard wrote:
> > 1. Turns out curl is available in PHP, and it lets you make POST requests
> > and set POST fields, which is what we need, so that looks good.
> > Something which the file / readfile functions don't do, only GET for them,
> > it seems?
> >
> > WOndering if there is another, better method than curl?  The issue is that
> > curl via php is single-session, meaning that when a lot of requests are
> > being generated on a server, they'll all be non-Keep-alive.  Just means
> > greater overhead, but I guess we can worry about it when we get to that
> > point.
>
> Hm.  Is curl in PHP the same as the client library in Pear?

probably, yah.  pear needs libcurl to compile, iirc.  php's curl api is a
subset methinks, as the curl_multi_* functions only recently arrived
there.

> > 2. Not sure how HTTP DELETE method can be done, but maybe that's something
> > Lucas can look into.
>
> curl should do this.  at least, it works from the command line.

cool.

> > 3. I've been experimenting with php's XML parser - looks good, much better
> > than my earlier experiences led me to believe.  It's essentially a SAX
> > implementation with function "reference" callbacks, no?  It works,
> > anyways.
>
> My experiences with it a ways back were really awful, but recently it
> seems to have become usable.  very happy about that.  :)

Just noticed that php has an xslt engine - that totally rocks.  I'd been
writing a poor-man's extractor for generating arrays from xml leaf data,
and it wasn't pretty or sane.  trade-off is, xslt is cpu intensive (at
least under Java), and a limited application hand-rolled jobby might be
better in the long run, but I'm not gonna worry that for now.

ok, just did some tests and... feh!  libcurl and xslt don't seem to be
widely available!  I just put together a proof-of-concept script and tried
running it on three different servers.  Two don't have curl compiled in,
two don't have xslt_* support, and all are 4.1.x or later.  That stinks.

What does this mean?  Can't lean on XSLT to make this easy?  Anything I'm
not getting here?  Maybe it's back to hand-rolled xsl-lite.

libcurl support is a must, though, for POST.  Fallback would be coding a
socket client in PHP.  the fsockopen() man page has a POST example that
makes this seem not unreasonable.

current listening: http://webjay.org/by/damaged_roses/coolandcollected5

>
> >
> >
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
>
>
>
> Yahoo! Groups Links
>
>
> Yahoo! Groups Sponsor ad
>
>
>

On Fri, 6 Aug 2004, Kevin Prichard wrote:
> 1. Turns out curl is available in PHP, and it lets you make POST requests
> and set POST fields, which is what we need, so that looks good.
> Something which the file / readfile functions don't do, only GET for them,
> it seems?
>
> WOndering if there is another, better method than curl?  The issue is that
> curl via php is single-session, meaning that when a lot of requests are
> being generated on a server, they'll all be non-Keep-alive.  Just means
> greater overhead, but I guess we can worry about it when we get to that
> point.

Hm.  Is curl in PHP the same as the client library in Pear?

> 2. Not sure how HTTP DELETE method can be done, but maybe that's something
> Lucas can look into.

curl should do this.  at least, it works from the command line.

> 3. I've been experimenting with php's XML parser - looks good, much better
> than my earlier experiences led me to believe.  It's essentially a SAX
> implementation with function "reference" callbacks, no?  It works,
> anyways.

My experiences with it a ways back were really awful, but recently it
seems to have become usable.  very happy about that.  :)


>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>

1. Turns out curl is available in PHP, and it lets you make POST requests
and set POST fields, which is what we need, so that looks good.
Something which the file / readfile functions don't do, only GET for them,
it seems?

WOndering if there is another, better method than curl?  The issue is that
curl via php is single-session, meaning that when a lot of requests are
being generated on a server, they'll all be non-Keep-alive.  Just means
greater overhead, but I guess we can worry about it when we get to that
point.

2. Not sure how HTTP DELETE method can be done, but maybe that's something
Lucas can look into.

3. I've been experimenting with php's XML parser - looks good, much better
than my earlier experiences led me to believe.  It's essentially a SAX
implementation with function "reference" callbacks, no?  It works,
anyways.

Lucas, you said this on the webjay forum-

"A cool project: a playlist editor that ran from the console.

Another one: something that allowed you to have a custom home page, so
that your playlists are all there but the formatting and html is all
your own.

Lots more."

That's a good idea - what do you think of something along these lines-
a PHP function to which you pass a few parameterized HTML snippets.
It'd handle the task of contacting the webjay API, of requesting and
retrieving the results, then stitching that data together with your
HTML snippets to produce a finished slab-o-HTML.

wj_genhtml_playlist( username, password, shortname, headerTemplate,
trackTemplate )

For example:

<?
echo wj_genhtml_playlist(
   "lucas_gonze",
   "b@rrywh1terul3z",
   "barrywhite",
   "<table border='1'><tr><td>Playlist: %TITLE</td>
    <td>Desc: %DESCRIPTION</td>
    <td>Who: %USERNAME</td>
    <td>Tracks: %NUMTRACKS</td>
     ... ",
   "<tr><td>%FILENAME</td><td>%SITE</td><td>%TRACKSECS</td>
     ... "
);
?>

And what you'd get back is the slab of HTML with those %VARNAME
placeholders replaced with whatever field they represent in the API
data coming back over the wire.

This would be even simpler than the PHP API, and more approachable to
newbie PHP users.  It could be one of the first client for the PHP API.

What do you think?

I liked the old logo, but the new one is an awesome rendering of that
design.  very cool.

On Wed, 4 Aug 2004, Lucas Gonze wrote:

> zenguin.com/webjay
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>

cool! can't help code much, but glad to be the token windows test subject.

At 02:52 AM 8/4/2004 +0000, you wrote:

>Hello,
>
>This email message is a notification to let you know that
>a file has been uploaded to the Files area of the webjay-dev
>group.
>
>   File        : /Webjay PHP API/wj_php_api_0.0.1.txt
>   Uploaded by : kevin3prichard <kevin3prichard@...>
>   Description : Webjay PHP API interface definitions - first draft!
>
>You can access this file at the URL:
>http://groups.yahoo.com/group/webjay-dev/files/Webjay%20PHP%20API/wj_php_api_0.\
0.1.txt
>
>
>To learn more about file sharing for your group, please visit:
>http://help.yahoo.com/help/us/groups/files
>
>Regards,
>
>kevin3prichard <kevin3prichard@...>
>
>
>
>
>
>
>
>
>Yahoo! Groups Links
>
>
>
>

--------------------------------------------------
Brett Singer & Associates, LLC
240 West 44th Street
New York, NY 10036
ph: (212)575-0263
fax: (212)575-2240
http://www.brettsinger.com

zenguin.com/webjay

Hello,

This email message is a notification to let you know that
a file has been uploaded to the Files area of the webjay-dev
group.

   File        : /Webjay PHP API/wj_php_api_0.0.1.txt
   Uploaded by : kevin3prichard <kevin3prichard@...>
   Description : Webjay PHP API interface definitions - first draft!

You can access this file at the URL:
http://groups.yahoo.com/group/webjay-dev/files/Webjay%20PHP%20API/wj_php_api_0.0\
.1.txt

To learn more about file sharing for your group, please visit:
http://help.yahoo.com/help/us/groups/files

Regards,

kevin3prichard <kevin3prichard@...>

I fiddled around with php xml a bit, when I was thinking of writing an
xspf importer, and it was surprizingly not horrible.



On Tue, 3 Aug 2004, kevin3prichard wrote:

> In thinking about a PHP wrapper API for webjay, I get a facial tic
> thinking about getting PHP built to work with the right XML libs and
> apache.  Anybody have a better experience?  Maybe it's different with
> PHP 5 now.
>
> Guess I'll have to go thru the steps again to verify, but my point is
> that I have a feeling that PHP's inbuilt xml_* functions are not
> available everywhere with consistency.
>
> Would it help to have a hand-rolled native-PHP xml parser?  I found
> this-
>
> http://codewalkers.com/seecode/416.html
>
> Looks like it's just a xml_* wrapper though, not an independent xml
> parser.
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>

In thinking about a PHP wrapper API for webjay, I get a facial tic
thinking about getting PHP built to work with the right XML libs and
apache.  Anybody have a better experience?  Maybe it's different with
PHP 5 now.

Guess I'll have to go thru the steps again to verify, but my point is
that I have a feeling that PHP's inbuilt xml_* functions are not
available everywhere with consistency.

Would it help to have a hand-rolled native-PHP xml parser?  I found
this-

http://codewalkers.com/seecode/416.html

Looks like it's just a xml_* wrapper though, not an independent xml
parser.

HTTP::Proxy::BodyFilter::save is a good basis to start from.

Only available in the cvs version of HTTP::Proxy.

On Mon, 2 Aug 2004, kevin3prichard wrote:

> That's an interesting idea.  I guess it could save some bandwidth for
> the user, and the content host too.
>
> Just to spell some of the benefit out... on the media player client-
> side:
>
> - Would keep previously-played content available when client machine
> is offline, or servers unavailable.
> - Meaning that, for proxy users, playlists don't have to go dark when
> the server's plug is pulled, if you've already played it with such a
> proxy in place.

From my perspective the benefits are saving on bandwidth, allowing offline
mode, and allowing files to keep their URLs aftering downloading.

The other thing is creating a pluggable location for all client side
functionality.  EG having a place to detect whether your mp3 player can
handle oggs, and coercing mime types.

> If the web browser is also proxied by the same server instance, it
> could have some playlist-level features as well:
>
> - Detect that a playlist has been requested, and be smart about pre-
> fetching newly requested content
> - If playlists are being cached, it could still register a hit on
> webjay.org, just to keep the numbers going there
>
> There are perhaps more features that don't meet the eye, that would
> become apparent once such a proxy is in use.
>
> Cons:
>
> - This is a geeky thing.  It'll be better for geeks at this point,
> not so well-suited for end-users.

yup.

> - That's okay, it makes a great proof-of-concept vehicle.

yup.

> - It doesn't seem to know about byte-range requests.  That would be a
> necessary modification, as recent players allow seek-ahead by making
> HTTP byte-range requests.

Good catch.  Yup.


>
> It's written in Perl, so it could be compiled to a Win32 executable
> using ActiveState perl, given an installation wrapper and tcl/tk
> dialogs to communicate with the user.
>
> The proxy could also be modified to interact better with the user via
> HTML or DHTML.  Thinking of a configuration window (as opposed to
> editing the source file -blech for users), and errors that need user
> feedback to resolve.
>
>
> --- In webjay-dev@yahoogroups.com, Lucas Gonze <lgonze@p...> wrote:
>>
>> One way to approach the problem of a decent client is to create a
> hackable
>> caching proxy.  This might be a decent basis:
>>
>> http://perlmonks.thepen.com/13927.html
>
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>

That's an interesting idea.  I guess it could save some bandwidth for
the user, and the content host too.

Just to spell some of the benefit out... on the media player client-
side:

- Would keep previously-played content available when client machine
is offline, or servers unavailable.
- Meaning that, for proxy users, playlists don't have to go dark when
the server's plug is pulled, if you've already played it with such a
proxy in place.

If the web browser is also proxied by the same server instance, it
could have some playlist-level features as well:

- Detect that a playlist has been requested, and be smart about pre-
fetching newly requested content
- If playlists are being cached, it could still register a hit on
webjay.org, just to keep the numbers going there

There are perhaps more features that don't meet the eye, that would
become apparent once such a proxy is in use.

Cons:

- This is a geeky thing.  It'll be better for geeks at this point,
not so well-suited for end-users.
- That's okay, it makes a great proof-of-concept vehicle.
- It doesn't seem to know about byte-range requests.  That would be a
necessary modification, as recent players allow seek-ahead by making
HTTP byte-range requests.

It's written in Perl, so it could be compiled to a Win32 executable
using ActiveState perl, given an installation wrapper and tcl/tk
dialogs to communicate with the user.

The proxy could also be modified to interact better with the user via
HTML or DHTML.  Thinking of a configuration window (as opposed to
editing the source file -blech for users), and errors that need user
feedback to resolve.


--- In webjay-dev@yahoogroups.com, Lucas Gonze <lgonze@p...> wrote:
>
> One way to approach the problem of a decent client is to create a
hackable
> caching proxy.  This might be a decent basis:
>
> http://perlmonks.thepen.com/13927.html

One way to approach the problem of a decent client is to create a hackable
caching proxy.  This might be a decent basis:

http://perlmonks.thepen.com/13927.html

At 01:52 PM 8/2/2004 -0400, you wrote:

> > does anyone know who is behind delicious?
>
>yup.  :)
>

it's you, isn't it?

have you approached him/her?

> does anyone know who is behind delicious?

yup.  :)

At 11:05 AM 8/2/2004 -0400, you wrote:
>Wanted: a gateway to convert calls that use the delicious api to calls
>that use the webjay api and vice versa.  That is, it should be possible
>for code which is written for one to access the other given just a change
>in domain name.
>
>See:
>http://del.icio.us/doc/api
>http://webjay.org/api/help
>

that would be pretty hot.

does anyone know who is behind delicious?

Wanted: a gateway to convert calls that use the delicious api to calls
that use the webjay api and vice versa.  That is, it should be possible
for code which is written for one to access the other given just a change
in domain name.

See:
http://del.icio.us/doc/api
http://webjay.org/api/help

Unsorted comments --

This list is Kevin's idea.  I think it's a good idea, and am happy to see
it happen.  I'll probably use this list to make technical announcements
relevant to wj.  It'll also be a very good place to archive important info
about URLs and bugs that affect development.

About a PHP API, I think flat out that that's a great idea.

- Lucas

My name is Kevin Prichard.  By day I code in Java, perl and PHP,
mostly creating database-driven websites for clients, and I also do
some Unix system management.  I like what i do, and get a kick out of
creating software gadgets that other people find useful.

One of the first things I'd like to see for Webjay is a PHP API.  PHP
is very popular for creating websites.  Creating an API that wraps
Webjay database access would make the creation of webjay-sibling
websites a much, much easier task.  There are probably many ways to go
about this; here are some ideas.

1. A flat PHP-style functional API that sends requests to webjay.org,
and returns arrays of data that contain playlists, tracks, etc.

2. An object-oriented API.  I guess you could define a class that
represents a Webjay user session, give it methods that do all the
usual Webjay stuff: log in, log out, get a playlist, play a playlist,
create playlist, etc.

It would be good to make a list of the individual functions that
webjay provides... soon!

This list is for discussing development related to the awesome
Webjay.org website.  Lucas Gonze is the guy behind it; he put a lot of
thought and time into creating Webjay - and it shows.  Thanks, Luc!

Webjay is a unique and cutting-edge service.  The function it offers
is simple and neat: create a list of MP3 URLs (or Real, .avi, .mpeg or
what-have-you), and now you can play this list through your favorite
media player on any workstation connected to the internet, and share
the list with others via a single URL.

That model -the creating, playing and sharing of playlists- naturally
wants to expand out to more endpoints.  For example, providing the
glueware necessary to download and listen to playlists on your
portable MP3 player, and eventually the ability to create playlists on
your player and share those back up to Webjay.org.  Creating
Webjay-alike websites that also offer playlist creation but perhaps
with a more specific focus.  Webjay offers an HTTP-based API for
communicating with its internal database over the 'net.

Webjay is exciting to the many people who've encountered it and visit
regularly not least because it features another unique service - it
offers easy introductions to new music and musicians.  I personally
have encountered many, many new groups, and genres even, that aren't
in radio play and may never be.  The utility of this feature only gets
better with more people, playlists and tracks added to Webjay's
already copious database.

What I hope to get from this mailing list is more detailed discussion
about features that can improve Webjay.  Discussions on how to create
websites that subscribe to Webjay's database API, and perhaps a group
collaboration toward creating Webjay APIs in the various languages
popular for website development (php, perl, java, asp) are welcome and
hopefully a core kickoff discussion.  It would be equally awesome to
begin discussion about plugins and embedded features (for web browsers
and players), a more advanced topic, but appropriate when the time
comes.

This intro email wouldn't be complete if it didn't mention the other
service Webjay has come to be used for - video playlists.  Brett
Singer is one of the people who have been creating them, and has ended
created some pretty cool things.

There have been some issues related to hosting video playlists on
Webjay, such as the accurate identification of mime-types for specific
URLs.  It seems that many web servers are not correctly configured to
serve an appropriate HTTP "Content-type" header for certain video file
types.  There have been some discussions on the Webjay forum about how
to deal with this.

http://www.webjay.org/geeklog-1.3.8-1sr2/public_html/forum/viewtopic.php?forum=1\
&showtopic=400

There's also been recent discussion of creating Webjay players using
Flash:

http://www.webjay.org/geeklog-1.3.8-1sr2/public_html/forum/viewtopic.php?forum=6\
&showtopic=452#682

That's it for now... I guess we should to post a link to this list
somewhere on Webjay.