Mongrel users - Nov 2006 - mongrel_upload_progress question/possible suggestion

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/mongrel-users/attachments/20061113/7a62f41e/attachment-0001.html

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.

Brad

On 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 at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/mongrel-users/attachments/20061113/bb6e0f84/attachment.html

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,

Matt

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.
>
> Brad
>
> On 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''] =~ <at> 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-GrnCvJ7WPxnNLxjTenLetw at public.gmane.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>
>

-- 
Thermal Creative
http://blog.thermalcreative.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/mongrel-users/attachments/20061114/594d7f4e/attachment-0001.html

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,

Matt

On 11/14/06, Brad Ediger <brad at bradediger.com>
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.
>
> Brad
>
> On 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 at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>
>
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>
>

-- 
Thermal Creative
http://blog.thermalcreative.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/mongrel-users/attachments/20061114/ce16d900/attachment.html

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

Brad

On 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,
>
> Matt
>
> On 11/14/06, Brad Ediger <brad at bradediger.com> 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.
>
> Brad
>
> On 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 at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/mongrel-users
>
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>
>
>
>
> -- 
> Thermal Creative
> http://blog.thermalcreative.com
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/mongrel-users/attachments/20061113/030ac87d/attachment.html

Brad (and anyone else),

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 <brad at bradediger.com>
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
>
> Brad
>
> On 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,
>
> Matt
>
> On 11/14/06, Brad Ediger <brad at bradediger.com> 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.
> >
> > Brad
> >
> > On 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 at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/mongrel-users
> >
> >
> >
> > _______________________________________________
> > Mongrel-users mailing list
> > Mongrel-users at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/mongrel-users
> >
> >
>
>
> --
> Thermal Creative
> http://blog.thermalcreative.com
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>
>
>

-- 
Thermal Creative
http://blog.thermalcreative.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/mongrel-users/attachments/20061114/900c7e15/attachment.html

Looks nice. Glad to hear it''s  working well.

On Nov 13, 2006, at 7:23 PM, Matt White wrote:
> Brad (and anyone else),
>
> 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 <brad at bradediger.com> 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
>
> Brad
>
> On 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,
>>
>> Matt
>>
>> On 11/14/06, Brad Ediger < brad at bradediger.com> 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.
>>
>> Brad
>>
>> On 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 at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/mongrel-users
>>
>>
>> _______________________________________________
>> Mongrel-users mailing list
>> Mongrel-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/mongrel-users
>>
>>
>>
>>
>> -- 
>> Thermal Creative
>> http://blog.thermalcreative.com
>> _______________________________________________
>> Mongrel-users mailing list
>> Mongrel-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/mongrel-users
>
>
>
>
> -- 
> Thermal Creative
> http://blog.thermalcreative.com
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/mongrel-users/attachments/20061113/062dd7f0/attachment-0001.html