+1 to named params. Please please please. :)
= is my vote for syntax. Makes sense. Doesn't make sense to introduce another
way to express something we've been used to for years with key = value, and is
it that important to save one character per assignment?
On Sep 6, 2013, at 9:39 AM, Nikita
On Feb 21, 2013, at 1:56 AM, Zeev Suraski z...@zend.com wrote:
There used to be a language that was the Queen of the Web. It was full of
clever syntax. It prided itself on having a variety of expressive ways of
doing the same thing. You're on the mailing list of the language that
On Thu, Feb 21, 2013 at 10:13 AM, Pascal Chevrel pascal.chev...@free.fr wrote:
I am specifically thinking of Bugzilla which is already used by many open
source projects. It has a lot more features than your current bug tracking
system, it scales for large projects and it has a few Mozilla
On 02/19/2013 11:22 PM, Klaus Ufo wrote:
Hi there !
We all know that the current PHP API has flaws. Maybe we could use namespaces
to build a new coherent PHP API ? Like :
- \arr
- \num
- \str
and so on. Advantages :
- no more global functions
- separation of concerns
- backward
On Wed, Feb 20, 2013 at 3:23 PM, Wim Godden wim.god...@cu.be wrote:
I agree that in most cases, that's a good thing. But it's also how we ended
up with a thing called the Y2k problem : stuff running forever.
Disclaimer : I've been developing with PHP since 1997, so I'm very fond of
the
It feels like this is just using classes for the sake of using
classes, adding an unnecessary layer of complexity (and discussion)
for no real reason except that is the RFC authors preference.
+1
First the discussion was filtering vs escaping. Now it is about how to
implement it as a class
On Wed, Sep 19, 2012 at 9:08 AM, Andrew Faulds a...@ajf.me wrote:
Yes, but typing the encoding every time is cumbersome. Or, if you don't want
to set it every time, you'd have to set it globally. Then, you forgot to
change it back somewhere when you're dealing with multiple encodings, and it
On Wed, Sep 19, 2012 at 9:16 AM, Lars Strojny l...@strojny.net wrote:
There seems to be a need for a procedural API. As their is one, let’s do it
similar to how MySQLi etc. does it and use a context resource:
$ctx = escape_context_create('UTF-8');
$str = escape_html_attr($ctx, $str);
why
On Wed, Sep 19, 2012 at 9:21 AM, Michael Stowe m...@mikestowe.com wrote:
Andrew, I'm the biggest advocate of OOP out there, but the purpose of this
is to provide a nice convenient layer for all developers to use to properly
escape code and increase security within their applications. As such,
On Wed, Sep 19, 2012 at 10:11 AM, Andrew Faulds a...@ajf.me wrote:
Please explain in detail how object-oriented code obfuscates, complicates,
murders baby kittens, etc.
Because a simple str_replace one line will become 6-10 lines of OO
code very easily?
Maybe you write amazing OO code, but
On Sep 19, 2012, at 10:22 AM, Andrew Faulds a...@ajf.me wrote:
Again, all the OOP code is a waste of time doesn't really add anything to
this discussion. Arguing against this being OOP, which I think is useful and
requires, at most, one extra line ($x = new Escaper), is silly.
Arguing
On Sep 19, 2012, at 10:55 AM, Pádraic Brady padraic.br...@gmail.com wrote:
I have never once expressed a problem with this being a set of
procedural function. Not once. The RFC offers some suggested function
signatures. So nobody has expressed any issues and nobody has insisted
that you be
On Tue, Sep 18, 2012 at 10:32 AM, Pádraic Brady padraic.br...@gmail.com wrote:
Hi Michael,
See the link near the bottom of the RFC - even htmlspecialchars() has
unusual behaviour that's potentially insecure. I have no objections to
there being functions, of course, and the RFC makes that
On Sep 18, 2012, at 5:00 AM, Paul Dragoonis dragoo...@gmail.com wrote:
Yep, I see where my suggestion for filter_var() isn't relevant.
I use symfony2's ecaper in the PPI\Templating\ component, and really like it.
Zend2's also seems pretty good.
It'd be nice to have this available as a
Also as there is also htmlspecialchars() which most people use for escaping
this seems like a better, more centralized functionality and better
nomenclature for escaping on output in general with options for various types
(and should just be utf-8 by default :))
--
PHP Internals - PHP Runtime
Personally I would want to have an audit log of emails on production. That
actually is probably more important to me than non-production environments :)
On Jan 27, 2012, at 1:37 AM, Martin Jansen mar...@divbyzero.net wrote:
Is there any intention behind enabling the mail.add_x_header
+1 the way for change is to add the new, add an E_DEPRECATED style
warning for a point release or two, and then nix it.
On Sun, Jul 3, 2011 at 2:04 PM, Kiall Mac Innes ki...@managedit.ie wrote:
FPM is still new, and only just getting the experimental flag removed, now
is the only time to make
Why doesnt voting happen using a poll/voting engine. Written in (gasp) PHP!
(although soon PJSON)
On Jun 3, 2011, at 1:03 AM, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
Voting on the wiki? Yuck. If you want participation, do it here on the
mailinglist and store the record in the
On Wed, Jun 1, 2011 at 1:01 PM, Pierre Joye pierre@gmail.com wrote:
I modified the vote page, pls move your votes to the desired syntax
(or global -1)
This is a good idea to group things like this.
Back on the soapbox. All of this is just to reduce typing array (5
characters) before
First, why not go the opposite way and standardize the syntax - why
not make object() or Object() work like array() or Array()?
$person = object('name' = 'Justin',
'city' = 'ogden',
'state' = 'ut',
'country' = 'usa',
'favoriteNumbers' = array(4, 12, 37, 42),
'unluckyNumbers' =
On Wed, Jun 1, 2011 at 3:09 PM, Sean Coates s...@seancoates.com wrote:
This is not about saving five characters every time I type array(), it's
about making my systems all work together in a way that's a little less
abstracted, and a lot less prone to error.
Why not make your data in JSON
Forgive me for injecting my $.02 here but what is the original reason
for changing the most basic language syntax to be a little bit
shorter?
Is it hurting anyone to type out array() or something?
I think it is silly that shortening array syntax is up for
discussion but ensuring Unicode
On Tue, May 31, 2011 at 3:06 PM, Rasmus ras...@lerdorf.com wrote:
Because most of those can't be done without breaking millions of lines
of code out there. And a couple of people worked on Unicode for years
and got very little support. That is not a small project. This short
syntax for arrays
I've always considered json an awesome machine to machine interchange format
(the most efficient one) but not the easiest to read for configuration or
manually defining anything.
I see nothing wrong with the initial example. Has worked well for years. :)
On May 31, 2011, at 3:43 PM, Marcel
I don't really want to stand on my soapbox any longer, as it's obvious
where the crowd leans on this one, but I need to clarify a couple
points a bit and feel obligated to reply to another.
On Tue, May 31, 2011 at 10:15 PM, Stas Malyshev smalys...@sugarcrm.com wrote:
Fundamental changes means
Personally I'd love to see an option to make it spit out an array. Just like te
second parameter in json_decode()
Since array keys can include colons prefix work would also be easier. Then
something akin to array2XML() to spit it back out.
On Apr 26, 2011, at 7:43 PM, Tom Samplonius
On Thu, Dec 9, 2010 at 2:31 AM, James Butler
james.but...@edigitalresearch.com wrote:
Sorry, I wasn't being very clear there, what I really meant to say was will
there be the will to remove it considering the effects.
I suppose INI is enough to allow it to be easily changed, but would it ever
On Thu, Dec 9, 2010 at 2:38 AM, Andrey Hristov p...@hristov.com wrote:
Yes, as the documentation will mention how to do it, for old applications.
For new apps it is easy - pass all the information you need as parameter to
the function. It works in other languages, why shouldn't it work for
2010/12/9 Ángel González keis...@gmail.com:
Not to mention, I have had issues (and I can't reproduce it properly
or I would report it) where sometimes i will have a variable in global
scope in one file, and I have to reference it as $GLOBALS['variable']
in another include, or I have to global
On Thu, Oct 21, 2010 at 12:52 AM, Ionut G. Stan ionut.g.s...@gmail.com wrote:
Option 5: Implement named parameters?
Option 6: do as other have and just pass an array yourself...
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Thu, Oct 21, 2010 at 1:10 AM, Ferenc Kovacs i...@tyrael.hu wrote:
With #6, you would lose the argument hinting(either be native, or phpdoc)
feature for your method.
you would, however
a) it's already supported
b) there's no language changes required
c) do your own typecasting, sanity
On Fri, Oct 15, 2010 at 10:26 AM, G M greg...@gregory.net wrote:
Okay so I am thinking about submitting a patch to PHP that would enable you
to call functions like this:
stuff(1, 2, 'separator' = 'br', 'clean' = true);
I don't like having the never ending growing list of arguments issue,
but
On Fri, Oct 8, 2010 at 2:47 AM, jvlad d...@yandex.ru wrote:
Hi.
This was discussed before.
see
http://www.mail-archive.com/internals@lists.php.net/msg37211.html
Tyrael
I have a question after reading through that thread -
apc.include_once_override - boolean, default is 0
Optimize
I would like to know why a third party can develop a better (or more agile?)
cache than the core php devs. I would think that if anyone can align it nicely
especially when writing the core code itself and could also think about this
is a great place for apc to hook in or something. It's
Is this only useful for 5.2.x and is it only for realpath() or is it for any
sort of path lookup and caching? Like resolving include paths and such?
On Jun 20, 2010, at 6:37 AM, Rasmus Lerdorf ras...@lerdorf.com wrote:
realpath_cache_size = 256k
realpath_cache_ttl = 7200
--
PHP Internals -
Perhaps by adding it to core the original reasons for alternatives will be
reduced and the things that make those special could be implemented into apc?
On Jun 20, 2010, at 1:56 PM, Ferenc Kovacs i...@tyrael.hu wrote:
On Sun, Jun 20, 2010 at 10:39 PM, Lukas Kahwe Smith
On Thu, Apr 15, 2010 at 12:09 AM, Ferenc Kovacs tyr...@gmail.com wrote:
My suggestion is more about releasing the allocated memory as soon as
possible. That is, this option is similar to max_requests.
PHP-FPM would kill the PHP process if the requests a process handled
exceed max_requests,
On Apr 15, 2010, at 4:55 AM, Zeev Suraski z...@zend.com wrote:
Agreed that it's a big change, but it's certainly possible.
Requires its own discussion...
Fwiw +1
Mysql's ini file supports includes (!includedir and it supports
wildcards), so people are used to the syntax and it can
2010/4/13 Zeev Suraski z...@zend.com:
What he means is that it'll be implemented in the custom code responsible
for parsing fpm.ini, and not in the ZE .ini parser which would be the layer
below it. Implementing include() can be done at either layer. If it's
implemented at the bottom layer
2010/3/25 Jérôme Loyet jer...@loyet.net:
** Default Section **
Talking about redundancy. When there is more than one pool, there is
several parameters which remain the same. Why should we type them
several time ? The idea is to define a special pool, which will not be
started but only be
On Thu, Mar 25, 2010 at 12:47 PM, Antony Dovgal t...@daylessday.org wrote:
You can as well stop declaring (!?) what FPM should and what it shoud not
and start doing something useful instead.
Writing some code might be a good start for you.
As someone Andrei somewhat entrusted to try to keep
2010/3/25 dreamcat four dreamc...@gmail.com:
If you intend to implement this Jerome, then perhaps (any time when /
after you implement), just make new (seperate) RFC for that (just the
ini). Which (obviously) can be attached as single dependancy of this
RFC. That way, those comments /
2010/3/25 Jérôme Loyet jer...@loyet.net:
Is there any sapi with directives in php.ini ? I can't see any reasons
to have some FPM specifics into php.ini.
To change the default conf file, juste specified it in the commande
line like any other daemon you have running on your boxes.
php-fpm
2010/3/23 Stanislav Malyshev s...@zend.com:
Actually, if you have extension parsing the .ini, nobody prevents you from
having:
include[]=another.ini
and have your extension interpret it as it wishes (i.e parse another file).
Only problem you have is if you want PHP to do it automatically
On Tue, Mar 23, 2010 at 10:25 AM, Antony Dovgal t...@daylessday.org wrote:
sapi/fpm and sapi/cgi now have quite different codebase as we've dropped some
stuff
not pertinent to FastCGI (there might be some leftovers, I'll deal with them
later).
Not sure if it's best to say it here or just
On Tue, Mar 23, 2010 at 12:43 PM, Antony Dovgal t...@daylessday.org wrote:
I mentioned it, albeit briefly:
* basic SAPI status info (similar to Apache mod_status)
Missed it (oops)
We've discussed this many times and I thought it's pretty clear that php.ini
syntax won't fit in this situation
2010/3/23 Jérôme Loyet jer...@loyet.net:
In fact with INI syntax, there is a serious missing cause there is no
include system shiped with. And with FPM as there is potentialy many
vhosts, it's necessary to have an include system to feet all system
administrator needs.
That was something I
On Tue, Mar 23, 2010 at 1:55 PM, Antony Dovgal t...@daylessday.org wrote:
Now I was never an XML fan myself, but I think THIS particular XML config file
is even easier to read and understand than php.ini.
There was one other suggestion / something Andrei wanted to do (at
least he mentioned to
On Tue, Mar 23, 2010 at 2:58 PM, Antony Dovgal t...@daylessday.org wrote:
Okay, here is XML based config quickly converted to php.ini-style syntax:
==
[fpm.flobals]
pid_file = /usr/local/var/run/php-fpm.pid
error_log =
NOTE: I just remembered there -is- a config-file-scan-dir option at
compile time. However, what about doing away with this and making it
inline in php.ini, the syntax can match mysql, as it uses ini files as
well.
This mainly will help with programatically creating PHP-FPM pool
config files, but
-Dec-2009, at 21:47, Johannes Schlüter johan...@schlueters.de wrote:
On Wed, 2009-12-23 at 04:40 -0800, Michael Shadle wrote:
NOTE: I just remembered there -is- a config-file-scan-dir option at
compile time. However, what about doing away with this and making it
inline in php.ini, the syntax can
On Wed, Dec 23, 2009 at 10:13 AM, Mikko Koppanen mkoppa...@php.net wrote:
Hello,
I think you can use PHP_INI_SCAN_DIR environment variable which should
work runtime as well.
still seems a bit archaic. i don''t see any reason why include support
can't be added in php.ini. it will probably
On Wed, Dec 23, 2009 at 10:47 AM, Pierre Joye pierre@gmail.com wrote:
Please tell me one benefit except we support include? I don't see
any. The extra files are still there, they will be loaded too, etc.
Instead of a -single location- being defined at compile time or
execution of PHP time,
On Wed, Dec 23, 2009 at 2:23 PM, Pierre Joye pierre@gmail.com wrote:
So what you need is multiple ini dirs, not actually include. I think
there is a patch somewhere for this feature, or it may even be already
in. If not, that could be something useful.
To me, it solves all of the usage
On Wed, Dec 23, 2009 at 5:12 PM, Mikko Koppanen mkoppa...@php.net wrote:
Hi,
I think this is the feature (in trunk currently):
http://svn.php.net/viewvc?view=revisionrevision=28287
This is not the same, this is just an additional way to still have
static dirs defined only at compile time, or
On Tue, Dec 15, 2009 at 4:25 AM, Antony Dovgal t...@daylessday.org wrote:
Here we have time, pid, function and line.
With log_level=debug all of them are printed, in other cases only time gets
into the log,
which makes perfect sense to me.
+1 to Antony and Jérôme.
Having a log format
2009/12/9 Zeev Suraski z...@zend.com:
We should be using INI unless there are compelling reasons against it, now
that this project becomes a part of the PHP source tree. As far as I can
tell there are no such compelling reasons and it can actually map quite
nicely into INI, hence, that's
I see it more like:
fpm.global.daemonize = yes
fpm.global.error_log = /var/log/php-fpm.log
or skip global:
fpm.daemonize = yes
fpm.error_log = /var/log/php-fpm.log
for each worker pool:
fpm.worker1.name = pool1
fpm.worker1.address = 127.0.0.1:9000 ; or socket
fpm.worker1.uid = www-data
2009/12/9 Jérôme Loyet jer...@loyet.net:
do you mean that it would be included in the global php.ini file ? I
never imagine that. For me it's an independant conf file
(/etc/php-fpm.conf for example).
correct. I don't see any reason for a different configuration file anymore
--
PHP Internals
2009/12/9 Jérôme Loyet jer...@loyet.net:
is there a way to include files ?
include /etc/php-fpm/*.conf ? with one file per worker for example ?
I think adding include to ini should not be a problem if it's not already
done.
I would love to see the php ini file support includes like MySQL
PM, Michael Shadle mike...@gmail.com wrote:
- Per-pool php.ini file (should be easy)
Why would you need that given that we have host, path or .user.ini
support? Which has to be backported to FPM as far as I know.
Cheers,
--
Pierre
http://blog.thepimp.net | http://www.libgd.org
--
PHP
On Tue, Dec 8, 2009 at 2:47 AM, Pierre Joye pierre@gmail.com wrote:
Why would you need that given that we have host, path or .user.ini
support? Which has to be backported to FPM as far as I know.
you're probably right. i mainly am only thinking of PHP_INI_SYSTEM and
things the user
On Tue, Dec 8, 2009 at 10:57 AM, Stanislav Malyshev s...@zend.com wrote:
How real would be the case of 2 hosts in the same pool having same configs,
but the same hosts in different pool having different configs?
I never though about that but I can tell you I use all my websites
under the same
On Mon, Dec 7, 2009 at 1:25 AM, Antony Dovgal t...@daylessday.org wrote:
That's the thing I want to avoid, actually.
Moving something out of PHP just because you're afraid of its release cycles
means you make it harder to maintain, not easier.
Even if it is just the management component of
On Mon, Dec 7, 2009 at 2:01 AM, Michael Shadle mike...@gmail.com wrote:
On Mon, Dec 7, 2009 at 1:25 AM, Antony Dovgal t...@daylessday.org wrote:
That's the thing I want to avoid, actually.
Moving something out of PHP just because you're afraid of its release cycles
means you make it harder
Sent from my iPhone
On Dec 7, 2009, at 5:57 AM, Jérôme Loyet jer...@loyet.net wrote:
2009/12/7 Reinis Rozitis r...@roze.lv:
- See if the normal libevent or libev could handle all the needs and
not a patched copy anymore (or get with the libevent team)
Isn't this is allready done since
For #2 it might no longer be needed that might be up for debate. It's
nice to be able to override a single option. But 5.3 with it's
htaccess/htscanner behavior might work good enough for most things
(but PHP_INI_SYSTEM might be still nice to override one offs instead
of having to point to
The problem with running a static amount of processes is trying to
figure out the right number. Also it is not elastic in any fashion.
Shared hosts would love the elasticity as it will allow sites to flex
up and down as needed without giving each individual user more
processes than they
2009/12/7 Jérôme Loyet jer...@loyet.net:
so you're saying each worker just has a worker.name prefixed
worker.name = pool1
worker.user = nobody
worker.group = nogroup
worker.static.max_children = 5
worker.dynamic.max_children = 20
worker.dynamic.start_servers = 5
worker.dynamic.min_spare_servers
Antony - thank you so much! This is quite a surprise though, I didn't
know there were plans for this... I was talking to gwynne on IRC about
the best way to get this going.
I suppose it being a separate SAPI works, but I had also thought:
What if it was just a modification to the FCGI SAPI, and
what version of PHP-FPM code is this based off of? the latest 0.6.x at
launchpad or one of the older patches?
we have had reports of some issues with php 5.3.x and php-fpm 0.6.x.
Andrei had changed the code from being a patch to being a standalone
daemon that builds against vanilla php sources
On Sat, Nov 21, 2009 at 9:16 PM, Arpad Ray array...@googlemail.com wrote:
However it would be a significant BC break, as old serialized session
records would be unreadable after upgrading. We could mitigate this by
providing a script to convert old session files.
I would say just a note
On Wed, Sep 9, 2009 at 1:01 AM, Jani Taskinenjani.taski...@iki.fi wrote:
Very good point. And I did consider only merging the _good_ parts of this
thing. I haven't had time to check the code yet at all (quite busy at work
right now) but there are some stuff it does we haven't generally
On Tue, Sep 8, 2009 at 8:58 PM, Stanislav Malyshevs...@zend.com wrote:
As for bundling libevent, I have no idea if BSD code can be put in php
tree... It'd be much nicer if these chanegs were merged into libevent - it
seems to be pretty alive, 3 releases this year.
That's what I've been
I think it would be a good idea to also include PHP-FPM in your investigation.
On Wed, Jul 1, 2009 at 11:02 AM, Gelu Kelundengelu.k...@gmail.com wrote:
Hi,
I'm trying to understand how difficult it is to create a new SAPI, so I
started to poke my nose inside the cgi SAPI source code. I saw
configure flags to
enable FastCGI, and so forth. In 5.3 they were unified completely: you
can't have one without the other anymore. Why would you need to?
-- Gwynne
Michael Shadle mike...@gmail.com wrote in message
news:bd9320b3090707q4fc2c2c3hbffbf289679e6...@mail.gmail.com ...
I
Namespaces in PHP are scaring me.
I can only imagine some of my developers creating code and using
namespaces - and how do you identify which namespace a function, class
or chunk of code is under?
It looks like you can define namespaces anywhere.
If I'm looking for a specific function, and it's
Andrei has turned the project over to me, and I am trying to keep it
going full steam ahead.
Rasmus told me the only thing stopping it from being adopted into PHP
or PECL was the license. That has now changed.
I don't believe it can be done in PECL, as it needs too many changes
in PHP core.
It
On Fri, Jun 26, 2009 at 12:14 PM, Stanislav Malyshev s...@zend.com wrote:
Hi!
It would be great if someone would examine the impact of adopting it
as the FastCGI SAPI replacement or looking at what hooks are required
to get it in and perhaps keep the userland stuff in PECL...
Why it
I can provide multiple machines as well from single chip dual core to
quad chip quad core...
Sent from my iPhone
On Jun 26, 2009, at 3:29 PM, Hannes Magnusson hannes.magnus...@gmail.com
wrote:
Hi all
Is there *anyone* who needs anything to be able to debug bug reports,
run sanitychecks,
Succinct and great reply.
Better webserver: nginx :)
#3 is probably the most important piece.
I'd like to also note scaling php is pretty simple. Scaling out
typically provides better results as opposed to scaling up. Scaling
your datastore will always be your pain point. Adding new data
On Mon, May 25, 2009 at 1:38 PM, Ilia Alshanetsky i...@prohost.org wrote:
Neat idea. Why not open the sqlite db at MINIT rather then RINIT and add a
whole pile of overhead to every request.
Ilia Alshanetsky
Also:
Pinba is something else that might be interesting to look into.
On Mon, May 18, 2009 at 4:38 AM, Christian Schneider
cschn...@cschneid.com wrote:
There's a big difference between changing some rare features (and no,
5.3 needs - almost no to - no changes with the code bases I know) and
removing something *everybody* uses.
Apart from the fact that _REQUEST
I think this strikes a good balance between backward compatibility...
I would hope though the code for it is very simple, to not add
overhead to PHP. Basically in PHP the pseudocode equivalent would be
if(ini_get('reigster_request') == true) {
$_REQUEST = array_merge($_GET, $_POST, $_COOKIE,
On Fri, May 15, 2009 at 1:32 AM, Lukas Kahwe Smith m...@pooteeweet.org wrote:
The more stuff like this we remove, the harder it becomes for people to
quickly move to newer, faster and more secure versions of PHP. That
causes way more frustration for everyone than a few ugly legacy
features.
On Fri, May 15, 2009 at 1:25 PM, Lukas Kahwe Smith m...@pooteeweet.org wrote:
Confusing new code is totally different from breaking existing code.
True but aren't some changes in 6.0 at least (and possibly 5.3) going
to require code changes? Or is it still going to be legacy enough ?
There's
On Thu, May 14, 2009 at 10:05 AM, Pierre Joye pierre@gmail.com wrote:
Hi,
On Thu, May 14, 2009 at 6:21 PM, Ilia Alshanetsky i...@prohost.org wrote:
We have a fair number of fixes in the 5.2 branch already and while 5.3 is
making very good progress I think it is still ways off in terms of
To me, it basically creates some laziness and reintroduces a vector on
the register_globals issue.
I've been using $_GET $_POST $_COOKIE $_SESSION $_SERVER etc. since
they were introduced, and have never had any problems. Was there a
reasoning behind making a variable that essentially glues them
On Thu, May 14, 2009 at 3:03 PM, Nathan Rixham nrix...@gmail.com wrote:
bc? all the reasoning in the world won't justify it to 1 million businesses
running php 4 code which is reliant on $_REQUEST behind the scenes.
although it would generate a tonne of freelance work :p
that code has to
89 matches
Mail list logo
