Login | Register
My pages Projects Community openCollabNet

Discussions > dev > Re: An extention for MaxQ

Discussion topic

Back to topic list

Re: An extention for MaxQ

Author oliverbock
Full name Oliver Bock
Date 2006-04-04 15:36:50 PDT
Message Hi Olivier et Fran├žois,

I think it makes sense for the delay information to be available for all
generators, so I think it should be included in the main part of MaxQ.
Non-ISAC generators can ignore this information, at least for now.
(Perhaps later they will include it in a comment.) As to whether the
HTTP headers are a good place to get the information, I do not know what
is available there. Why would this more complicated approach be
superior to simply using the system clock? If the test uses more than
one computer you may have problems with unsynchronised clocks or clocks
in different time zones.

I think that using a configuration file for ISAC settings is a good
idea, although a dialog box would also be OK. Can I suggest that you
add ISAC-specific settings to maxq.properties rather than creating a new
configuration file? It may be difficult to clearly delineate properties
that relate to MaxQ versus properties that relate to ISAC. You will
presumably use maxq.properties to select your ISAC generator, so perhaps
it makes sense to also specify the ISAC plugin there. It also reduces
the number of files and the complexity of the configuration code. (i.e.
you can simply add some new settings to Config.java.) However I do not
feel strongly about this and would not be bothered if you preferred a
separate file.


Olivier Lecrivain wrote:
> We are currently working on the ISAC code generator. In ISAC scenario,
> we need to specify a delay between each request and it seems that the
> current HttpHeaderRequest doesn't extract the date from the headers.
> We think we have two ways to fix this. On one hand we could keep the
> time between each request in our generator. On the other hand we could
> enhance HttpHeaderRequest, making it records the date from the headers
> and calculate the delay between two requests by substracting their
> date. Can we have your advice on this point?
> In addition, we need to configure how our generator records the
> requests (for example we can choose which ISAC plugin to use). We
> think that adding an options window in the GUI would be a bit tricky.
> Are you ok if we add a property file in the conf directory which will
> do this configuration work?
> Best regards,
> Olivier Lecrivain, Fran├žois Vinassac
> On 3/31/06, *Oliver Bock* <oliver at g7 dot org <mailto:oliver@g7​.org>> wrote:
> On 31/03/2006, at 18:16, Bruno Dillenseger wrote:
>> Encryption is inherent to HTTPS and so you are right in
>> considering that the proxy approach looks like a man-in-the-middle.
>> We could consider the way OpenSTA's capture proxy solves this
>> problem, by changing https://... URIs to http://{... URIs and
>> having the proxy manage the HTTPS protocol with the server and
>> record whatever necessary without encryption problem.
>> See:
>> http://portal.openst​a.org/modules.php?op​=modload&name=ph​pWiki&file=index​&pagename=Record​ingHttps
>> <http://portal.openst​a.org/modules.php?op​=modload&name=ph​pWiki&file=index​&pagename=Record​ingHttps>
>> http://portal.openst​a.org/modules.php?op​=modload&name=Ne​ws&file=article​&sid=5
>> <http://portal.openst​a.org/modules.php?op​=modload&name=Ne​ws&file=article​&sid=5>
>> So, to sum up:
>> - probably there is nothing to change about MaxQ (we just have to
>> check the abstract script generation interface),
>> - HTTPS support could probably be introduced, based for instance
>> on OpenSTA's trick.
> Having read all the text required to explain the http://{ trick,
> and read about the IE bug, and considered that it won't solve URLs
> embedded in CSS files, JavaScript or other client-side
> technologies, I think that the solution they rejected is superior:
> MaxQ should be man-in-the-middle. The cost is a single warning at
> the start of recording. In exchange we get reliable recording
> that requires little explanation.
> Oliver

« Previous message in topic | 3 of 4 | Next message in topic »


Show all messages in topic

Re: An extention for MaxQ oliverbock Oliver Bock 2006-03-30 14:33:50 PST
     Re: An extention for MaxQ oliverbock Oliver Bock 2006-03-31 01:25:02 PST
         Re: An extention for MaxQ oliverbock Oliver Bock 2006-04-04 15:36:50 PDT
             Re: An extention for MaxQ oliverbock Oliver Bock 2006-04-05 00:54:39 PDT
Messages per page: