Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:65723 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 58915 invoked from network); 7 Feb 2013 18:25:55 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 7 Feb 2013 18:25:55 -0000 Authentication-Results: pb1.pair.com smtp.mail=nikita.ppv@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=nikita.ppv@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.172 as permitted sender) X-PHP-List-Original-Sender: nikita.ppv@gmail.com X-Host-Fingerprint: 209.85.217.172 mail-lb0-f172.google.com Received: from [209.85.217.172] ([209.85.217.172:65335] helo=mail-lb0-f172.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id A0/85-23848-2B1F3115 for ; Thu, 07 Feb 2013 13:25:55 -0500 Received: by mail-lb0-f172.google.com with SMTP id n8so2363424lbj.31 for ; Thu, 07 Feb 2013 10:25:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=wzLuGi3NjZzjNMkqxV4cZyf07iuT7YV39wNoI1F7too=; b=K5Eao7NAJz/6HbaQGpte3d2wFWHvZiAEK0JbMFj+boeJutT0Si/gW1h1T0Vsuz3vX/ DPVzdVrZ3SShjCjj00f6cAyoodcy5I26Sfnh0DeEbcBXgTJTRKgPaZmfuhnylmMwheVy OiFMQ80y64Bntz//rKj8q/8942okZy1kF1s3JUw7RGbNcO7P8fo0LiXj5g+Hpgr1twfw NxfQZyffR4DIhuVRohtFqS9T75svb9AtEOWrQtp9zSKI1+w7ePffDCNZIpn9/MPAYSW8 9EUXx95klzb5eGDa7QWN2VNTaReichX9JXDi5h6c+IO1kFC8wrimFbTG7Mudheztjmkk uyag== MIME-Version: 1.0 X-Received: by 10.152.162.1 with SMTP id xw1mr2289384lab.3.1360261551571; Thu, 07 Feb 2013 10:25:51 -0800 (PST) Received: by 10.112.138.131 with HTTP; Thu, 7 Feb 2013 10:25:50 -0800 (PST) In-Reply-To: <5113AE8F.4060402@2bepublished.at> References: <2B76A3EF-66AC-4E73-B186-236E9C2AE891@gmail.com> <5113AE8F.4060402@2bepublished.at> Date: Thu, 7 Feb 2013 19:25:50 +0100 Message-ID: To: Christoph Rosse Cc: PHP internals Content-Type: multipart/alternative; boundary=f46d042ef4a595428804d5269260 Subject: Re: [PHP-DEV] [RFC] Improved Linux process title support in the CLI SAPI From: nikita.ppv@gmail.com (Nikita Popov) --f46d042ef4a595428804d5269260 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Feb 7, 2013 at 2:39 PM, Christoph Rosse wrote: > why wouldn't this go into core? setting the name of the current > php-process is definitely something everyone that develops php-cli scripts > could use. > I use a lot of php-cli scripts and I've never seen the need. Without having hard data to back this up, I am pretty sure that this applies to nearly all php-cli scripts. > We should not base the decision of putting something into the core on > assumptions on how many people are going to use the feature. > Obviously we should. Whether people will use it is pretty much the most important aspect for deciding whether or not something should be added. Even a trivial addition is a loose for the project if nobody is going to use it. And this is no trivial addition. This seems to be quite a bit system dependent and uses some odd methods like overwriting argv memory. And on that note, it also has to copy the argv data if I got that right, which is something it has to do always and not just when people are actually using the feature ;) I'm not saying I'm against this feature. I'd just really appreciate it if we could drop the good old "it doesn't matter if people are going to use it" non-arguments and instead provide a bit more info for people like me, who are not in the process-title-hacking business. I.e. what this is needed for an why this is needed in core. E.g. what Arvid mentioned, that this is useful when you are running many PHP-based daemons and want to distinguish them. That's the kind of stuff I'd like to see in the RFC. Regarding core/non-core. People mentioned that this is not implementable as an extension. That can be either solved by putting it into core or by adding the necessary API hook ;) [I'm not arguing which variant is better, just saying that not being implementable with current core does not mean that we can't make it implementable :)] Thanks, Nikita --f46d042ef4a595428804d5269260--