This is what I finally came up with:
def upload_notify(action, params, *args)
return unless @path_info.any? { |ptrn| ptrn.is_a?(Regexp) ? params['PATH_INFO'] =~ ptrn : params['PATH_INFO'] == ptrn } &&
params[Mongrel::Const::REQUEST_METHOD] == 'POST' &&
upload_id = Mongrel::HttpRequest.query_parse(params['QUERY_STRING'])['upload_id']
if action == :mark
last_checked_time = Mongrel:: Uploads.last_checked(upload_id)
return unless last_checked_time && Time.now - last_checked_time > @frequency
end
Mongrel::Uploads.send(action, upload_id, *args)
Mongrel:: Uploads.update_checked_time (upload_id) unless action == :finish
end
Basically, if it finds a Regexp in the path array it will do a pattern match. Otherwise it will just do the original string equality check. This should have the least performance impact possible while still allowing you to do regex if you so desire.
I tested it with httperf and it seemed to have no effect on performance compared to 0.2 and 0.2.1.
Thoughts?
Matt
On 11/14/06, Brad Ediger
<[EMAIL PROTECTED]> wrote:
My mistake; I forgot that this was in the m_u_p gem, and I don't think it's been pushed to the gem servers yet. Try installing from this:http://mongrel.rubyforge.org/releases/gems/mongrel_upload_progress-0.2.1.gem
BradOn Nov 13, 2006, at 2:18 PM, Matt White wrote:First off, sorry if this is a dupe. Having some mail issues...
Anyway,
Brad,
Thanks for the reply... I'm going to do a bit of benchmarking to see how bad it is. My problem is that in my quest to stay DRY I have a few id's in my path, and so there really isn't any way to create an array of paths that has all of the possible combinations (at least, not before it's WAY worse than using regexes ;). I suppose I could create a controller that does nothing but handle uploads, though that wouldn't be as DRY.
I didn't see your array testing code in the mongrel_upload_progress 0.2. That's the bit of code I updated, and I think that's in a different tree than Mongrel. Am I missing it? If I switch to a different routing layout, your method may be better, esp if it's faster.
Thanks,
MattOn 11/14/06, Brad Ediger < [EMAIL PROTECTED]> wrote:I'm pretty sure that decision was made for performance reasons... nontrivial regexes take significantly more processing than string matching. If you have actual concerns about performance, you should always benchmark ( http://mongrel.rubyforge.org/docs/how_many_mongrels.html).I used an array for this purpose... you can say :path_info => ['one path', 'another path' ... ]. I think Zed checked my patch for that in to svn, and I'm pretty sure it's available in the 0.3.13.4 prerelease.
BradOn Nov 13, 2006, at 1:57 AM, Matt White wrote:Hey all,
First off, thanks to Rick Olson and whoever else was involved with this plugin... It's been amazingly easy to implement.
I've got a question about the path_info parameter, though... It seems that unless the request PATH_INFO exactly matches the path_info passed in to the plugin at inclusion, it won't actually trigger Add and add the upload to the list of running transfers. I'm assuming that this is for performance reasons, and makes good sense. However, I'm in a situation where I don't know the exact path that I will b e uploading from, because of various routing info in my app.
Thus, the ability for path_info to be a regex instead of just a string, thus allowing for:
return unless params['PATH_INFO'] =~ @path_info &&
params[Mongrel::Const::REQUEST_METHOD] == 'POST' &&
upload_id = Mongrel::HttpRequest.query_parse(params['QUERY_STRING'])['upload_id']
Then I just update my handler like so:
uri "/",
:handler => plugin("/handlers/upload", :path_info => %r{/account/\d/\d/media/upload}),
:in_front => true
And everything works fine... It's a super-small tweak, obviously, but I found that it made it a lot easier for me to use the plugin.
Thoughts? Is there a better way to do this?
Matt
--
Thermal Creative
http://blog.thermalcreative.com_______________________________________________Mongrel-users mailing list
_______________________________________________
Mongrel-users mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/mongrel-users
--
Thermal Creative
http://blog.thermalcreative.com_______________________________________________Mongrel-users mailing list
--
Thermal Creative
http://blog.thermalcreative.com
_______________________________________________ Mongrel-users mailing list [email protected] http://rubyforge.org/mailman/listinfo/mongrel-users
