> Well, yes, I keep forgetting this. Ok, I see there's docs in pylon's > documentation on how to handle file uploads in $pylons-docs/forms.html > (locally compiled copy) > > Hmmm. Instead of cpoying the temp file with copyfileobj, is there no > possibility of moving/linking it to the final destination? request -> > memory -> disk -> memory -> disk is extremely silly and hard on the poor > RAID. (This is without research, I'll look into what python/pylons offers > later.)
Oh please. How about a splitter that splits up the arriving bytes by parity and transmits them over two distinct NICs to the SAN to lessen the wear on their respective silicon? If you want control on that level, you are going to have to write something yourself. Last time I checked, my harddrive needed 2secs to write 100MB. And we're talking notebook here, not high-end server iron. So I guess once somebody has spent the better part of an hour (or even more so) squeezing 100MB through his 1MBit uplink, I presume he won't mind the extra few seconds to move that stuff around. Besides, moving files is most often just a re-linking,. > (... and generally, I have the feeling that it is assumed that somebody > starting with tg better had some idea what pylons does. Well, I don't, and > I how am I supposed to know when is it ok to "fall back" to just using > pylons stuff and when am I supposed to use tg specific stuff?) If there is something TG-specific, use it. If not, look around. Yes, docs need (as always) enhancing, and recipes added for common use-cases. Care about helping out? Diez --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/turbogears?hl=en -~----------~----~----~----~------~----~------~--~---
