caching images locally, multipart downloads, and the age of WSGI/CherryPy

[Yoni Samlan]

So I've messed around a bit now with the edna source (enough to add in
new xspf playlist serving and an embedded flash mp3 player) and had a
few observations.

One is that the HTTP server doesn't seem to be caching images. I tried
loading one of my larger folders with a few hundred subfolders, and
the image file for the identical folder icons was making a new request
to the edna server each time. slow, inefficient and eating my
bandwidth for no good reason. Is there an easy fix for this? It seems
like it'd just be a matter of sending the right headers in the http
responses. Then I tried some other stuff which failed (multipart
chunked downloading with DownThemAll! in firefox) and got me to
looking and thinking.

edna's advantage is its super-lightweightness, of course - enough to
make up for the looks, features, and shiny GUI configurability it
lacks in the default configuration when compared with gigantic apps
like SubSonic or MyTunesRSS. After all, most of MyTune's features that
take 7 MB (zipped) to implement even above the 60+ MB in the Java
runtime are implemented just dandily in the few dozen kilobytes in
edna.

But edna also has what in my eyes is a sort of brittle
long-if-then-chain approach to being an http server. No offense to the
community that coded it - after all, considering the state of Python
and web services when Edna was started, it's aged pretty well, and it
certainly does its job with a minimum of code.

But enter 2007, and the era of Django, Twisted, and asynchronous HTTP
requests in javascript. The http stack in edna isn't quite up to
robustly handling the way some stuff works (try using a multipart
download manager on Edna, for example)- it's fairly brittle and not
always nice about "doing the right thing" from the modern HTTP server
point of view. It's not supposed to be Apache+mod_python, of course,
but you know what I mean.

I was toying today with the idea of either grafting edna's cool
content-generating parts onto a CherryPy app (
http://www.cherrypy.org/ ), or messing with some other more robust but
still lightweight http python server. It seems like a pretty good fit
for what edna does, and might even allow some shrinking of the Edna
code (and reduce the likelihood of introducing bugs in the server
section) if the cherryPy parts could be left unmodified from their
base... but it'd also add 286 KB to the underlying code and/or a
dependency package for edna.

I guess my point is: Is it time for edna to get with WSGI, or am I
starry-eyed and hypnotized by hype like Ruby On Rails developers? Is
there interest in porting to a new http server, but think I'm wrong
about which one to use? Or am I totally off-base here?

Or am I really talking about something that, while interesting, would
be going off in a totally different direction than edna- a
slightly-less-lightweight webapp that wouldn't really be right to call
edna at all? After all - I'm talking about a standards-compliant fully
OO app, and the spirit of edna seems to be 'i am the little
thousand-line-script that can.'

- Yoni

p.s. Sorry if I'm overstepping my bounds here, I know I've been a
code-contributing member for all of five days now, and I really do
like edna and all the cool stuff it can do for a 50-odd KB download.
This is absolutely not meant to put down the work people have put in
to edna, but feel free to shoot me down or set me straight, I'll
understand :)
_______________________________________________
edna mailing list
edna@...
http://mailman.lyra.org/mailman/listinfo/edna

[hydatech]

I would have to say jump right in Yoni,
I just caught up with some of the progress you made and I'm impressed. If you got the time and energy tinker away! thats what OS projects are supposed to be about anyhow. I'm more of a sys admin guy and less of a programmer otherwise I would be up for collaborating but I (and I'm sure others) would be happy to offer feedback with whatever you choose to work on.
Sincerely
-j

On 3/26/07, Yoni Samlan <yoni@...> wrote:

So I've messed around a bit now with the edna source (enough to add in
new xspf playlist serving and an embedded flash mp3 player) and had a
few observations.

One is that the HTTP server doesn't seem to be caching images. I tried
loading one of my larger folders with a few hundred subfolders, and
the image file for the identical folder icons was making a new request
to the edna server each time. slow, inefficient and eating my
bandwidth for no good reason. Is there an easy fix for this? It seems
like it'd just be a matter of sending the right headers in the http
responses. Then I tried some other stuff which failed (multipart
chunked downloading with DownThemAll! in firefox) and got me to
looking and thinking.

edna's advantage is its super-lightweightness, of course - enough to
make up for the looks, features, and shiny GUI configurability it
lacks in the default configuration when compared with gigantic apps
like SubSonic or MyTunesRSS. After all, most of MyTune's features that
take 7 MB (zipped) to implement even above the 60+ MB in the Java
runtime are implemented just dandily in the few dozen kilobytes in
edna.

But edna also has what in my eyes is a sort of brittle
long-if-then-chain approach to being an http server. No offense to the
community that coded it - after all, considering the state of Python
and web services when Edna was started, it's aged pretty well, and it
certainly does its job with a minimum of code.

But enter 2007, and the era of Django, Twisted, and asynchronous HTTP
requests in javascript. The http stack in edna isn't quite up to
robustly handling the way some stuff works (try using a multipart
download manager on Edna, for example)- it's fairly brittle and not
always nice about "doing the right thing" from the modern HTTP server
point of view. It's not supposed to be Apache+mod_python, of course,
but you know what I mean.

I was toying today with the idea of either grafting edna's cool
content-generating parts onto a CherryPy app (
http://www.cherrypy.org/ ), or messing with some other more robust but
still lightweight http python server. It seems like a pretty good fit
for what edna does, and might even allow some shrinking of the Edna
code (and reduce the likelihood of introducing bugs in the server
section) if the cherryPy parts could be left unmodified from their
base... but it'd also add 286 KB to the underlying code and/or a
dependency package for edna.

I guess my point is: Is it time for edna to get with WSGI, or am I
starry-eyed and hypnotized by hype like Ruby On Rails developers? Is
there interest in porting to a new http server, but think I'm wrong
about which one to use? Or am I totally off-base here?

Or am I really talking about something that, while interesting, would
be going off in a totally different direction than edna- a
slightly-less-lightweight webapp that wouldn't really be right to call
edna at all? After all - I'm talking about a standards-compliant fully
OO app, and the spirit of edna seems to be 'i am the little
thousand-line-script that can.'

- Yoni

p.s. Sorry if I'm overstepping my bounds here, I know I've been a
code-contributing member for all of five days now, and I really do
like edna and all the cool stuff it can do for a 50-odd KB download.
This is absolutely not meant to put down the work people have put in
to edna, but feel free to shoot me down or set me straight, I'll
understand :)
_______________________________________________
edna mailing list
edna@...
http://mailman.lyra.org/mailman/listinfo/edna

_______________________________________________
edna mailing list
edna@...
http://mailman.lyra.org/mailman/listinfo/edna

[Christophe Kalt-5]

On Mar 26, Yoni Samlan wrote:
| One is that the HTTP server doesn't seem to be caching images. I tried
| loading one of my larger folders with a few hundred subfolders, and
| the image file for the identical folder icons was making a new request
| to the edna server each time. slow, inefficient and eating my
| bandwidth for no good reason. Is there an easy fix for this? It seems
| like it'd just be a matter of sending the right headers in the http
| responses.

Yes, i think edna falls a bit short of doing everything needed
for this.  It shouldn't be very hard to fix.

as you noted later in your mail, edna suffers from doing all
the HTTP implementation itself.
_______________________________________________
edna mailing list
edna@...
http://mailman.lyra.org/mailman/listinfo/edna

[Kumar McMillan]

On 3/26/07, Yoni Samlan <yoni@...> wrote:
> I guess my point is: Is it time for edna to get with WSGI

I think yes, WSGI is a smart direction.  This way it can be used with
a variety of different server implementations.
_______________________________________________
edna mailing list
edna@...
http://mailman.lyra.org/mailman/listinfo/edna