[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