Login | Register
My pages Projects Community openCollabNet

Discussions > dev > [maxq-dev] Anyone working on fixing the follow redirects?

maxq
Discussion topic

Hide all messages in topic

All messages in topic

Re: [maxq-dev] Anyone working on fixing the follow redirects?

Author hdara at primavera dot com
Full name hdara at primavera dot com
Date 2004-07-26 10:16:54 PDT
Message I don't know. I have only seen cases where a post redirects to a get,
which seems to work fine with parameters. I don't know about redirecting
to a post, but I think it is pretty much same.

henrik dot westman at uk dot bn​pparibas.com wrote on 07/26/2004 12:49:07 AM:

>
> If I remember correctly, I could not use parameters in the redirect
POST,
> in v0.93.
>
> Are you saying this is possible in v0.95 ?
>
>
> Regards,
> Henrik W.
>
>
>
>
>
> Extranet
> hdara at primavera dot com - 23/07/2004 20:40
>
>
> Please respond to dev at maxq dot tigris dot org
>
> To: dev
>
> cc:
>
>
> Subject: Re: [maxq-dev] Anyone working on fixing the follow
redirects?
>
>
> Please disregard this thread. I was under the impression that MaxQ
> actually doesn't record redirects, but I was wrong. I think it is doing
> the right thing, by recording the redirects and disabling the
> forward-redirects in HttpClient. I don't know why I thought so, may be
the
> older version did that way. But the reason it wasn't working in my case
> was due to some difference in the values of some temporary parameters
from
> record time. This is completely my application specific issue which I
have
> to deal with.
>
> Thank you,
> Hari
>
>
>
>
> Hari Krishna Dara/SF/DE/Primavera
> 07/22/2004 03:57 PM
>
> To
> dev at maxq dot tigris dot org
> cc
>
> Subject
> Re: [maxq-dev] Anyone working on fixing the follow redirects?
>
>
>
>
>
> Thanks for the response. But I don't understand why the browser behavior
> should impact MaxQ. There may be some issue here with HTTP to HTTPS, but
I
> didn't know if MaxQ supports it. If not, any variation in browser
behavior
> will also be recorded, so won't be just fine to play it back?
>
> Can anyone comment on the following TODO comment? What does "wmh" mean?
>
>
> public void doAssertResponse(String respCode) {
> StringBuffer result = new StringBuffer();
> result.append(create​Statement("print \"Response code: %s\" %
> self.getMethod().get​StatusCode()"));
> //hack: wmh redirects have a timing issue that can cause
assertion
> failures
> if(!respCode.startsWith("302")) {
> result.append(create​Statement("self.asse​rtEquals(\"Assert
> number " + ++assertNumber + " failed\", " + respCode +
> ", self.getMethod().get​StatusCode())"));
> }
> result.append(create​Statement("Validator​.validateResponse(se​lf,
> self.getMethod(), self.currentUrl, self.currentParams)"));
> getScriptAdapter().a​ppend(result.toStrin​g());
> }
>
> I am thinking that recording both the original request with the 302
> response code followed by the redirection request should work. Since
> HttpClient doesn't automatically handle redirects, it should play back
> fine. An additional check to make sure that the original redirection URL
> and the new one from the redirect response are same will be good. I will
> really appreciate any comments on this.
>
> Thank you,
> Hari
>
> Frank Cohen <fcohen at pushtotest dot com> wrote on 07/22/2004 11:29:04 AM:
>
> > Browsers handle HTTP redirects differently, especially when the
> > redirect goes from an HTTP to HTTPS connection. TestMaker uses the
> > HTTPUrlConnection class in Java and I've been thinking about creating
a
> > browser profile to control how redirects are processed. I haven't
> > gotten very far on it. -Frank
> >
> >
> >
> >
> > On Jul 22, 2004, at 11:20 AM, hdara at primavera dot com wrote:
> >
> > > Currently the follow redirects are not recorded and are disabled at
> > > runtime. This causes a serious limitation for us, because, unless
> > > certain
> > > URLs are accessed, the resources on the server are not created, so
the
> > > subsequent requests on the resource will fail. I would like to get
> this
> > > fixed, but if someone is already working on it, I would like to work
> > > with
> > > them to avoid duplicating the effort.
> > >
> > > Also I am not very much sure why recording of redirects was
disabled.
> I
> > > think I saw somewhere in the code a FIXME with an explicit disable
of
> > > this. All I can think of was that the old HTTPClient library didn't
> > > provide control to the programmer on how the redirects should be
> > > handled,
> > > so recording them resulted in duplicate requests and even worse,
> > > incorrect
> > > status codes. If commons HttpClient has better control on handling
> > > redirects, is it not easy enough to enable this part of the code
> > > again? I
> > > will be very much interested to here any thoughts from those who
knew
> > > the
> > > original problem and has ideas on how to get it working with the new
> > > library.
> > >
> > > I think this change will break the old scripts, so we will probably
> > > have
> > > to encode this information in the script (like an explicit call to
> > > enable
> > > the feature).
> > >
> > > Thank you,
> > > Hari
> > >
> > >
--------------------​--------------------​--------------------​---------
> > > To unsubscribe, e-mail: dev-unsubscribe at maxq dot tigris dot org
> > > For additional commands, e-mail: dev-help at maxq dot tigris dot org
> > >
> > >
> > ---
> > Frank Cohen, PushToTest, http://www.PushToTest.com, phone: 408 374
7426
> > Author of "Java Testing and Design: From Unit Tests to Automated Web
> > Tests"
> > from Prentice Hall, details at http://thebook.pushtotest.com
> >
> >
> > --------------------​--------------------​--------------------​---------
> > To unsubscribe, e-mail: dev-unsubscribe at maxq dot tigris dot org
> > For additional commands, e-mail: dev-help at maxq dot tigris dot org
> >
>
>
>
> --------------------​--------------------​--------------------​---------
> To unsubscribe, e-mail: dev-unsubscribe at maxq dot tigris dot org
> For additional commands, e-mail: dev-help at maxq dot tigris dot org
>
>
>
>
>
>
>
>
>
>
> This message and any attachments (the "message") is
> intended solely for the addressees and is confidential.
> If you receive this message in error, please delete it and
> immediately notify the sender. Any use not in accord with
> its purpose, any dissemination or disclosure, either whole
> or partial, is prohibited except formal approval. The internet
> can not guarantee the integrity of this message.
> BNP PARIBAS (and its subsidiaries) shall (will) not
> therefore be liable for the message if modified.
>
>
********************​********************​********************​********************​**************
>
> BNP Paribas Private Bank London Branch is authorised
> by CECEI & AMF and is regulated by the Financial Services
> Authority for the conduct of its investment business in the
> United Kingdom.
>
> BNP Paribas Securities Services London Branch is authorised
> by CECEI & AMF and is regulated by the Financial Services
> Authority for the conduct of its investment business in the
> United Kingdom.
>
> BNP Paribas Fund Services UK Limited is authorised and
> regulated by the Financial Services Authority.
>
>
> --------------------​--------------------​--------------------​---------
> To unsubscribe, e-mail: dev-unsubscribe at maxq dot tigris dot org
> For additional commands, e-mail: dev-help at maxq dot tigris dot org
>


--------------------​--------------------​--------------------​---------
To unsubscribe, e-mail: dev-unsubscribe at maxq dot tigris dot org
For additional commands, e-mail: dev-help at maxq dot tigris dot org

Re: [maxq-dev] Anyone working on fixing the follow redirects?

Author henrik dot westman at uk dot bnpparibas dot com
Full name henrik dot westman at uk dot bnpparibas dot com
Date 2004-07-26 00:49:07 PDT
Message If I remember correctly, I could not use parameters in the redirect POST,
in v0.93.

Are you saying this is possible in v0.95 ?


Regards,
 Henrik W.





Extranet
hdara at primavera dot com - 23/07/2004 20:40


Please respond to dev at maxq dot tigris dot org

To: dev

cc:


Subject: Re: [maxq-dev] Anyone working on fixing the follow redirects?


Please disregard this thread. I was under the impression that MaxQ
actually doesn't record redirects, but I was wrong. I think it is doing
the right thing, by recording the redirects and disabling the
forward-redirects in HttpClient. I don't know why I thought so, may be the
older version did that way. But the reason it wasn't working in my case
was due to some difference in the values of some temporary parameters from
record time. This is completely my application specific issue which I have
to deal with.

Thank you,
Hari




Hari Krishna Dara/SF/DE/Primavera
07/22/2004 03:57 PM

To
dev at maxq dot tigris dot org
cc

Subject
Re: [maxq-dev] Anyone working on fixing the follow redirects?





Thanks for the response. But I don't understand why the browser behavior
should impact MaxQ. There may be some issue here with HTTP to HTTPS, but I
didn't know if MaxQ supports it. If not, any variation in browser behavior
will also be recorded, so won't be just fine to play it back?

Can anyone comment on the following TODO comment? What does "wmh" mean?


    public void doAssertResponse(String respCode) {
        StringBuffer result = new StringBuffer();
        result.append(create​Statement("print \"Response code: %s\" %
self.getMethod().get​StatusCode()"));
        //hack: wmh redirects have a timing issue that can cause assertion
failures
        if(!respCode.startsWith("302")) {
            result.append(create​Statement("self.asse​rtEquals(\"Assert
number " + ++assertNumber + " failed\", " + respCode +
                ", self.getMethod().get​StatusCode())"));
        }
        result.append(create​Statement("Validator​.validateResponse(se​lf,
self.getMethod(), self.currentUrl, self.currentParams)"));
        getScriptAdapter().a​ppend(result.toStrin​g());
    }

I am thinking that recording both the original request with the 302
response code followed by the redirection request should work. Since
HttpClient doesn't automatically handle redirects, it should play back
fine. An additional check to make sure that the original redirection URL
and the new one from the redirect response are same will be good. I will
really appreciate any comments on this.

Thank you,
Hari

Frank Cohen <fcohen at pushtotest dot com> wrote on 07/22/2004 11:29:04 AM:

> Browsers handle HTTP redirects differently, especially when the
> redirect goes from an HTTP to HTTPS connection. TestMaker uses the
> HTTPUrlConnection class in Java and I've been thinking about creating a
> browser profile to control how redirects are processed. I haven't
> gotten very far on it. -Frank
>
>
>
>
> On Jul 22, 2004, at 11:20 AM, hdara at primavera dot com wrote:
>
> > Currently the follow redirects are not recorded and are disabled at
> > runtime. This causes a serious limitation for us, because, unless
> > certain
> > URLs are accessed, the resources on the server are not created, so the
> > subsequent requests on the resource will fail. I would like to get
this
> > fixed, but if someone is already working on it, I would like to work
> > with
> > them to avoid duplicating the effort.
> >
> > Also I am not very much sure why recording of redirects was disabled.
I
> > think I saw somewhere in the code a FIXME with an explicit disable of
> > this. All I can think of was that the old HTTPClient library didn't
> > provide control to the programmer on how the redirects should be
> > handled,
> > so recording them resulted in duplicate requests and even worse,
> > incorrect
> > status codes. If commons HttpClient has better control on handling
> > redirects, is it not easy enough to enable this part of the code
> > again? I
> > will be very much interested to here any thoughts from those who knew
> > the
> > original problem and has ideas on how to get it working with the new
> > library.
> >
> > I think this change will break the old scripts, so we will probably
> > have
> > to encode this information in the script (like an explicit call to
> > enable
> > the feature).
> >
> > Thank you,
> > Hari
> >
> > --------------------​--------------------​--------------------​---------
> > To unsubscribe, e-mail: dev-unsubscribe at maxq dot tigris dot org
> > For additional commands, e-mail: dev-help at maxq dot tigris dot org
> >
> >
> ---
> Frank Cohen, PushToTest, http://www.PushToTest.com, phone: 408 374 7426
> Author of "Java Testing and Design: From Unit Tests to Automated Web
> Tests"
> from Prentice Hall, details at http://thebook.pushtotest.com
>
>
> --------------------​--------------------​--------------------​---------
> To unsubscribe, e-mail: dev-unsubscribe at maxq dot tigris dot org
> For additional commands, e-mail: dev-help at maxq dot tigris dot org
>



--------------------​--------------------​--------------------​---------
To unsubscribe, e-mail: dev-unsubscribe at maxq dot tigris dot org
For additional commands, e-mail: dev-help at maxq dot tigris dot org










This message and any attachments (the "message") is
intended solely for the addressees and is confidential.
If you receive this message in error, please delete it and
immediately notify the sender. Any use not in accord with
its purpose, any dissemination or disclosure, either whole
or partial, is prohibited except formal approval. The internet
can not guarantee the integrity of this message.
BNP PARIBAS (and its subsidiaries) shall (will) not
therefore be liable for the message if modified.

********************​********************​********************​********************​**************

BNP Paribas Private Bank London Branch is authorised
by CECEI & AMF and is regulated by the Financial Services
Authority for the conduct of its investment business in the
United Kingdom.

BNP Paribas Securities Services London Branch is authorised
by CECEI & AMF and is regulated by the Financial Services
Authority for the conduct of its investment business in the
United Kingdom.
  
BNP Paribas Fund Services UK Limited is authorised and
regulated by the Financial Services Authority.


--------------------​--------------------​--------------------​---------
To unsubscribe, e-mail: dev-unsubscribe at maxq dot tigris dot org
For additional commands, e-mail: dev-help at maxq dot tigris dot org

Re: [maxq-dev] Anyone working on fixing the follow redirects?

Author hdara at primavera dot com
Full name hdara at primavera dot com
Date 2004-07-23 12:40:12 PDT
Message Please disregard this thread. I was under the impression that MaxQ
actually doesn't record redirects, but I was wrong. I think it is doing
the right thing, by recording the redirects and disabling the
forward-redirects in HttpClient. I don't know why I thought so, may be the
older version did that way. But the reason it wasn't working in my case
was due to some difference in the values of some temporary parameters from
record time. This is completely my application specific issue which I have
to deal with.

Thank you,
Hari




Hari Krishna Dara/SF/DE/Primavera
07/22/2004 03:57 PM

To
dev at maxq dot tigris dot org
cc

Subject
Re: [maxq-dev] Anyone working on fixing the follow redirects?





Thanks for the response. But I don't understand why the browser behavior
should impact MaxQ. There may be some issue here with HTTP to HTTPS, but I
didn't know if MaxQ supports it. If not, any variation in browser behavior
will also be recorded, so won't be just fine to play it back?

Can anyone comment on the following TODO comment? What does "wmh" mean?


    public void doAssertResponse(String respCode) {
        StringBuffer result = new StringBuffer();
        result.append(create​Statement("print \"Response code: %s\" %
self.getMethod().get​StatusCode()"));
        //hack: wmh redirects have a timing issue that can cause assertion
failures
        if(!respCode.startsWith("302")) {
            result.append(create​Statement("self.asse​rtEquals(\"Assert
number " + ++assertNumber + " failed\", " + respCode +
                ", self.getMethod().get​StatusCode())"));
        }
        result.append(create​Statement("Validator​.validateResponse(se​lf,
self.getMethod(), self.currentUrl, self.currentParams)"));
        getScriptAdapter().a​ppend(result.toStrin​g());
    }

I am thinking that recording both the original request with the 302
response code followed by the redirection request should work. Since
HttpClient doesn't automatically handle redirects, it should play back
fine. An additional check to make sure that the original redirection URL
and the new one from the redirect response are same will be good. I will
really appreciate any comments on this.

Thank you,
Hari

Frank Cohen <fcohen at pushtotest dot com> wrote on 07/22/2004 11:29:04 AM:

> Browsers handle HTTP redirects differently, especially when the
> redirect goes from an HTTP to HTTPS connection. TestMaker uses the
> HTTPUrlConnection class in Java and I've been thinking about creating a
> browser profile to control how redirects are processed. I haven't
> gotten very far on it. -Frank
>
>
>
>
> On Jul 22, 2004, at 11:20 AM, hdara at primavera dot com wrote:
>
> > Currently the follow redirects are not recorded and are disabled at
> > runtime. This causes a serious limitation for us, because, unless
> > certain
> > URLs are accessed, the resources on the server are not created, so the
> > subsequent requests on the resource will fail. I would like to get
this
> > fixed, but if someone is already working on it, I would like to work
> > with
> > them to avoid duplicating the effort.
> >
> > Also I am not very much sure why recording of redirects was disabled.
I
> > think I saw somewhere in the code a FIXME with an explicit disable of
> > this. All I can think of was that the old HTTPClient library didn't
> > provide control to the programmer on how the redirects should be
> > handled,
> > so recording them resulted in duplicate requests and even worse,
> > incorrect
> > status codes. If commons HttpClient has better control on handling
> > redirects, is it not easy enough to enable this part of the code
> > again? I
> > will be very much interested to here any thoughts from those who knew
> > the
> > original problem and has ideas on how to get it working with the new
> > library.
> >
> > I think this change will break the old scripts, so we will probably
> > have
> > to encode this information in the script (like an explicit call to
> > enable
> > the feature).
> >
> > Thank you,
> > Hari
> >
> > --------------------​--------------------​--------------------​---------
> > To unsubscribe, e-mail: dev-unsubscribe at maxq dot tigris dot org
> > For additional commands, e-mail: dev-help at maxq dot tigris dot org
> >
> >
> ---
> Frank Cohen, PushToTest, http://www.PushToTest.com, phone: 408 374 7426
> Author of "Java Testing and Design: From Unit Tests to Automated Web
> Tests"
> from Prentice Hall, details at http://thebook.pushtotest.com
>
>
> --------------------​--------------------​--------------------​---------
> To unsubscribe, e-mail: dev-unsubscribe at maxq dot tigris dot org
> For additional commands, e-mail: dev-help at maxq dot tigris dot org
>



--------------------​--------------------​--------------------​---------
To unsubscribe, e-mail: dev-unsubscribe at maxq dot tigris dot org
For additional commands, e-mail: dev-help at maxq dot tigris dot org

Re: [maxq-dev] Anyone working on fixing the follow redirects?

Author hdara at primavera dot com
Full name hdara at primavera dot com
Date 2004-07-22 15:57:31 PDT
Message Thanks for the response. But I don't understand why the browser behavior
should impact MaxQ. There may be some issue here with HTTP to HTTPS, but I
didn't know if MaxQ supports it. If not, any variation in browser behavior
will also be recorded, so won't be just fine to play it back?

Can anyone comment on the following TODO comment? What does "wmh" mean?


    public void doAssertResponse(String respCode) {
        StringBuffer result = new StringBuffer();
        result.append(create​Statement("print \"Response code: %s\" %
self.getMethod().get​StatusCode()"));
        //hack: wmh redirects have a timing issue that can cause assertion
failures
        if(!respCode.startsWith("302")) {
            result.append(create​Statement("self.asse​rtEquals(\"Assert
number " + ++assertNumber + " failed\", " + respCode +
                ", self.getMethod().get​StatusCode())"));
        }
        result.append(create​Statement("Validator​.validateResponse(se​lf,
self.getMethod(), self.currentUrl, self.currentParams)"));
        getScriptAdapter().a​ppend(result.toStrin​g());
    }

I am thinking that recording both the original request with the 302
response code followed by the redirection request should work. Since
HttpClient doesn't automatically handle redirects, it should play back
fine. An additional check to make sure that the original redirection URL
and the new one from the redirect response are same will be good. I will
really appreciate any comments on this.

Thank you,
Hari

Frank Cohen <fcohen at pushtotest dot com> wrote on 07/22/2004 11:29:04 AM:

> Browsers handle HTTP redirects differently, especially when the
> redirect goes from an HTTP to HTTPS connection. TestMaker uses the
> HTTPUrlConnection class in Java and I've been thinking about creating a
> browser profile to control how redirects are processed. I haven't
> gotten very far on it. -Frank
>
>
>
>
> On Jul 22, 2004, at 11:20 AM, hdara at primavera dot com wrote:
>
> > Currently the follow redirects are not recorded and are disabled at
> > runtime. This causes a serious limitation for us, because, unless
> > certain
> > URLs are accessed, the resources on the server are not created, so the
> > subsequent requests on the resource will fail. I would like to get
this
> > fixed, but if someone is already working on it, I would like to work
> > with
> > them to avoid duplicating the effort.
> >
> > Also I am not very much sure why recording of redirects was disabled.
I
> > think I saw somewhere in the code a FIXME with an explicit disable of
> > this. All I can think of was that the old HTTPClient library didn't
> > provide control to the programmer on how the redirects should be
> > handled,
> > so recording them resulted in duplicate requests and even worse,
> > incorrect
> > status codes. If commons HttpClient has better control on handling
> > redirects, is it not easy enough to enable this part of the code
> > again? I
> > will be very much interested to here any thoughts from those who knew
> > the
> > original problem and has ideas on how to get it working with the new
> > library.
> >
> > I think this change will break the old scripts, so we will probably
> > have
> > to encode this information in the script (like an explicit call to
> > enable
> > the feature).
> >
> > Thank you,
> > Hari
> >
> > --------------------​--------------------​--------------------​---------
> > To unsubscribe, e-mail: dev-unsubscribe at maxq dot tigris dot org
> > For additional commands, e-mail: dev-help at maxq dot tigris dot org
> >
> >
> ---
> Frank Cohen, PushToTest, http://www.PushToTest.com, phone: 408 374 7426
> Author of "Java Testing and Design: From Unit Tests to Automated Web
> Tests"
> from Prentice Hall, details at http://thebook.pushtotest.com
>
>
> --------------------​--------------------​--------------------​---------
> To unsubscribe, e-mail: dev-unsubscribe at maxq dot tigris dot org
> For additional commands, e-mail: dev-help at maxq dot tigris dot org
>


--------------------​--------------------​--------------------​---------
To unsubscribe, e-mail: dev-unsubscribe at maxq dot tigris dot org
For additional commands, e-mail: dev-help at maxq dot tigris dot org

Re: [maxq-dev] Anyone working on fixing the follow redirects?

Author fcohen
Full name Frank Cohen
Date 2004-07-22 11:29:04 PDT
Message Browsers handle HTTP redirects differently, especially when the
redirect goes from an HTTP to HTTPS connection. TestMaker uses the
HTTPUrlConnection class in Java and I've been thinking about creating a
browser profile to control how redirects are processed. I haven't
gotten very far on it. -Frank




On Jul 22, 2004, at 11:20 AM, hdara at primavera dot com wrote:

> Currently the follow redirects are not recorded and are disabled at
> runtime. This causes a serious limitation for us, because, unless
> certain
> URLs are accessed, the resources on the server are not created, so the
> subsequent requests on the resource will fail. I would like to get this
> fixed, but if someone is already working on it, I would like to work
> with
> them to avoid duplicating the effort.
>
> Also I am not very much sure why recording of redirects was disabled. I
> think I saw somewhere in the code a FIXME with an explicit disable of
> this. All I can think of was that the old HTTPClient library didn't
> provide control to the programmer on how the redirects should be
> handled,
> so recording them resulted in duplicate requests and even worse,
> incorrect
> status codes. If commons HttpClient has better control on handling
> redirects, is it not easy enough to enable this part of the code
> again? I
> will be very much interested to here any thoughts from those who knew
> the
> original problem and has ideas on how to get it working with the new
> library.
>
> I think this change will break the old scripts, so we will probably
> have
> to encode this information in the script (like an explicit call to
> enable
> the feature).
>
> Thank you,
> Hari
>
> --------------------​--------------------​--------------------​---------
> To unsubscribe, e-mail: dev-unsubscribe at maxq dot tigris dot org
> For additional commands, e-mail: dev-help at maxq dot tigris dot org
>
>
---
Frank Cohen, PushToTest, http://www.PushToTest.com, phone: 408 374 7426
Author of "Java Testing and Design: From Unit Tests to Automated Web
Tests"
from Prentice Hall, details at http://thebook.pushtotest.com


--------------------​--------------------​--------------------​---------
To unsubscribe, e-mail: dev-unsubscribe at maxq dot tigris dot org
For additional commands, e-mail: dev-help at maxq dot tigris dot org

[maxq-dev] Anyone working on fixing the follow redirects?

Author hdara at primavera dot com
Full name hdara at primavera dot com
Date 2004-07-22 11:20:07 PDT
Message Currently the follow redirects are not recorded and are disabled at
runtime. This causes a serious limitation for us, because, unless certain
URLs are accessed, the resources on the server are not created, so the
subsequent requests on the resource will fail. I would like to get this
fixed, but if someone is already working on it, I would like to work with
them to avoid duplicating the effort.

Also I am not very much sure why recording of redirects was disabled. I
think I saw somewhere in the code a FIXME with an explicit disable of
this. All I can think of was that the old HTTPClient library didn't
provide control to the programmer on how the redirects should be handled,
so recording them resulted in duplicate requests and even worse, incorrect
status codes. If commons HttpClient has better control on handling
redirects, is it not easy enough to enable this part of the code again? I
will be very much interested to here any thoughts from those who knew the
original problem and has ideas on how to get it working with the new
library.

I think this change will break the old scripts, so we will probably have
to encode this information in the script (like an explicit call to enable
the feature).

Thank you,
Hari

--------------------​--------------------​--------------------​---------
To unsubscribe, e-mail: dev-unsubscribe at maxq dot tigris dot org
For additional commands, e-mail: dev-help at maxq dot tigris dot org
Messages per page: