* Stephen J Baker <sjbaker@xxxxxxxx> [020304 10:27]: > On 4 Mar 2002, at 4:10, vio wrote: > > > After browsing the gimp-1.3 TODO list, I would like to add my little > > suggestion of things I would wish from Gimp: how about also developing > > a clear path towardsGimp as a "web graphics server". > > Wouldn't it make more sense to push Gimp's scripted rendering features > into the browser (as a plugin) and send just the script to the user's > machine for interpreting? It would presumably be a LOT less bandwidth > than sending out an image...particularly if you are doing animations. I don't understand what you mean by "Gimp's scripted rendering features"? That the Gimp plugin/script source code is stored on the browser side? And a browser plugin: which browser? Exactly. The client (the web browser) has no idea (nor interest to know!) who or how the pictures it receives from the web server are generated. The only difference in this situation is that those images are generated "after" the web server received the "request" from the client for that image. A good analogy would be with Dell's 'direct' distribution model: a Dell computer is assembled only "after" a customer has placed the order for it. Same here: Gimp assembles the pixels for the image only "after" the server has received an "order" for it (a request). Let's call this "Image On Demand". Obviously, most images on a web page will continue to be served "pre-assembled" (pre-cooked) images. But there is a market out there for images generated on the spot, bleeding fresh, photons still smoking. Examples could be any images who age very fast (stock graphs come to mind, though it's not the best example) or images who are dependent on the client's request (so they couldn't have been generated beforehand since the server had no idea what the client's parameters for that image was before it made the request). Yes, this is a very resource-intensive proposition, as opposed to static images, but CPU speeds are getting faster, RAM is getting cheaper. And hopefully bandwidth providers will follow suit. I managed to put my hand on a "Net-Fu" package. Yes, that is what I was talking about. I wonder if this code is still maintained by anyone, because what I got had a 1997 timestamp. I hope the authors won't mind, but if I can manage to get rid of the Java code (for their client), and re-write the server in python, we're in business (not that I have personally anything against Java or C). Regards, Vio
