>From the little I read of Ben's work with Ajax (see the thread called something like "Ajax is the next black"), this shows some promise.
But I'm still not convinced web pages and web servers are the conceptually "right" way to drive something like Slim. Web pages, with their essentially "stateless" architecture, require a lot of repeated information to be sent back and forth. This, of course, costs. It's not the underlying web server that's expensive, it's what we're trying to pump through it. Some things about the Slim display, for instance, player status, change second by second and cannot be cached. Other things, like the name of that Gloria Estephan tune, don't change for days. But there's no way to cache the relatively stable data in a web server - the unit of caching is the entire page. I had a small driver app that I wrote for my audiotron. It drove the audiotron through their web interface. When I got my squeezebox, back in server 5.4 days, I converted it to use the web server provided by 5.4. There was a version of the interface that was specifically to be driven by software. It returned current status about current players. It was fast. I could hand it 10 or so queries a second, useful for immediate feedback that the volume knob you're turning is actually end-to-end working. I did the visual feedback on the knob by the responses from the web server. It was very good, and also pointed out the odd time when the server was ignoring me - knob doesn't show itself turning, it didn't happen. But I got my song data by scanning the files myself (that code was written back in the audiotron days and I didn't remove it). So any queries like "who sang 'lets dance'?" were satisifed outside the web server paradigm. The combination of web server for immediate feedback stuff and cached data for the database made for a very responsive app. Were I to write it today, I'd probably fetch the entire database at startup time over the web interface and cache it. I started to convert it to use the CLI (it's mostly done, but my damned day job flared up and I have had to stop development now for months). The CLI performance is probably half an order of magnitude better (for player status things) than the web server was. Since the web server was adequate, I think the CLI will be, if anything, better. Since I never use it to ask "how's your database?", I don't know how responsive that part is. But the point is, any web based app that is going to re-ask for that stuff at every refresh is going to be slow. Ajax tries, in some way I don't entirely understand, to get around that need by building caching at the app level for the stuff that need not be refetched every time. All discussions on this topic seem to have centered around the idea that you need to have the web interface in order to have platform independence. I'm not sure why. I understand that web browsers are ubiquitous, and they may be the only option for little closed handhelds, but as I understand it, any box big enough to run perl could run a custom app written in perl, perhaps using the perl forms package as part of the user interface and communicating with slimserver via the cli. That would keep your platform independence, at least across the broad group of platforms that can run perl. This would not invalidate web serving for the platforms that can only run a web browser, but for those platforms that can run something with a bigger footprint, would provide a much nicer, more responsive experience. -- Michaelwagner ------------------------------------------------------------------------ Michaelwagner's Profile: http://forums.slimdevices.com/member.php?userid=428 View this thread: http://forums.slimdevices.com/showthread.php?t=25321 _______________________________________________ discuss mailing list [email protected] http://lists.slimdevices.com/lists/listinfo/discuss
