W3C home > Mailing lists > Public > public-qt-comments@w3.org > May 2012

[Bug 17227] [QT3TS] fn-available-environment-variables-011

From: <bugzilla@jessica.w3.org>
Date: Wed, 30 May 2012 02:41:58 +0000
To: public-qt-comments@w3.org
Message-Id: <E1SZYrG-0006Zu-01@jessica.w3.org>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17227

--- Comment #2 from Liam R E Quin <liam@w3.org> 2012-05-30 02:41:57 UTC ---
I'm not sure in what way you would like me to address the report.

The motivation for adding the environment-variable() function was largely to
access user-settable environment variables, including e.g. HTTP headers when
invoked using a CGI interface.  Part of my goal was to make it easier (or even
possible) to use XQuery in some relatively hostile environments.

So it seems reasonable to test that you can set a variable to a particular
value.

I'd be OK with parameterising the name of the variable in some way, or changing
it to lower case, if it helps. I'd welcome suggestions. But I think the
principle behind the test case is valid - test whether a user can set a
variable to a specific value and retrieve it. And the point of environment
variables is that they provide a (very crude) mechanism  to communicate at a
process level. e.g. from bash or sh on Linux or Solaris or OS X (the Windows
mechanism is actually cross-process but otherwise similar).

An alternative might be to allow implementations to pass if QTTEST and QTTEST2
are not listed in the list of available variables.

Another alternative might be for your implementation to search first for
environment variables and then for system properties - there's no way to
prevent an implementation from making variables available that are *not* listed
in available-environment-variables(). And that might be more useful for users.

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Wednesday, 30 May 2012 02:42:00 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:57:38 UTC