NYCPHP Meetup

NYPHP.org

[nycphp-talk] [OT] live slide-show delivery via browser only

Rob Marscher rmarscher at beaffinitive.com
Tue Oct 31 13:13:53 EST 2006


I haven't heard of a free/OSS solution... but I agree it would be pretty 
simple to do like you described.  The viewers would have ajax code that 
would periodically ask the server if the slide has been updated.  The 
server-side script could send back the html for the current slide and 
the viewer code would replace the current slide with the new html.  The 
jquery javascript library makes this really easy.  Then you need a 
seperate client for the operator that would have the controls for 
forward/jump/back - that doesn't even have to be done with ajax.

I think the only minor concern here is to benchmark that your web server 
can handle the amount of polling that will be done by the ajax viewer 
client for the number of viewers that you expect.  You can put some kind 
of simple caching in the server-side viewer so that it doesn't really 
need to process anything during the polling... just send back the 
contents of a cache file that is recreated each time the operator 
changes the current slide.  You could also have the client keep track of 
the current slide id and it could send that to the server when it asks 
for an update.  The server could see if the slide id sent from the 
client matches the current slide and then tell the client it doesn't 
have to update anything.

-Rob

Allen Shaw wrote:
> Hi All,
>
> I'm looking for a free/OSS (preferably PHP-oriented) solution to this 
> problem:  Deliver paged content (eg., typical still-frame slide show) to 
> any number of viewers via the web browser only, while providing only the 
> host/operator with the controls to advance the slides in real time;  and 
> don't require the user to have anything other than a decent Internet 
> connection and fairly modern browser.
>
> If nobody knows of an existing package like this, it seems it would be 
> fairly simple to build, no?  Page-forward/back/jump commands could be 
> sent by the operator to a database or file on the server, and some 
> Javascript in the viewer could be monitoring the server for those 
> commands and then adjust the display accordingly. 
>
> Question: Is this
> a) so self-apparent and easy that nobody's bothered to develop a package 
> for it?
> b) much more complicated than I've explained and thus potentially a 
> waste of time?
> or
> c)  contained already in some fairly simple CGI package you know about 
> and I don't?
>
> Thanks,
> Allen
>
>   



More information about the talk mailing list