From rstoll at tutteli.ch  Tue Dec  3 04:24:44 2013
From: rstoll at tutteli.ch (Robert Stoll)
Date: Tue, 3 Dec 2013 10:24:44 +0100
Subject: [nycphp-talk] Type safety in PHP
In-Reply-To: <010f01cdf050$d24d8cc0$76e8a640$@tutteli.ch>
References: <010f01cdf050$d24d8cc0$76e8a640$@tutteli.ch>
Message-ID: <001801cef009$810f5280$832df780$@tutteli.ch>

Heya,

Quite a long time ago (almost a year), I asked you guys to fill in a survey about type safety in PHP which I conducted
in context of my bachelor thesis.
Unfortunately, I did not really have time to publish all results on a website so far but I am happy to announce that you
can find the results here now:
http://tsphp.tutteli.ch/wiki/display/TSPHP/Results+online+survey+Type+Safety+in+PHP

My bachelor thesis serves as a basis of the open source project TSPHP (Type-Safe PHP). You can find further information
about it on the wiki as well:
http://tsphp.tutteli.ch/wiki/display/TSPHP/Overview

Please don't hesitate if you have further questions about the survey or the project.

Cheers,
Robert


------
From: talk-bounces at lists.nyphp.org [mailto:talk-bounces at lists.nyphp.org] On Behalf Of Robert Stoll
Sent: Saturday, January 12, 2013 12:10 AM
To: talk at lists.nyphp.org
Subject: [nycphp-talk] Type safety in PHP

Hi,

I am currently working on my final project of my undergraduate study and the project is about type safety in PHP. One
aspect of the project examines the opinion of the PHP community on this topic.

I now need your help. I would be very glad, if you could take 5 - 20 minutes to fill in my online survey:
http://www.q-set.co.uk/q-set.php?sCode=PGSKQCJUWZVK

I will publish the deliverables of my project under an open source license. Thus you contribute automatically to an open
source project if you fill in the form :)

Thanks for your help
Robert Stoll



From anoland at indigente.net  Tue Dec  3 15:00:44 2013
From: anoland at indigente.net (Adrian Noland)
Date: Tue, 3 Dec 2013 14:00:44 -0600
Subject: [nycphp-talk] The SSL Certificate Scam
In-Reply-To: <529385B1.6010202@gmail.com>
References: <529385B1.6010202@gmail.com>
Message-ID: <CAHDX9B1j470+b66v_8RMVnqjyPS8+nF7iZcNpen=9R5oixWX0g@mail.gmail.com>

Sorry this is a bit late....

Check out the convergence.io project. Covers all the bases you mentioned.



On Mon, Nov 25, 2013 at 11:15 AM, Gary A. Mort <garyamort at gmail.com> wrote:

> Warning, this a a length rant/vent on the state of SSL certificates as
> used on websites today.
>
> https://plus.google.com/117506461184749864074/posts/PqHMSjsY5hp
>
> The summary is:
> I don't feel that purchasing SSL Certificates from "Trusted Third Parties"
> as defined by Google, Microsoft, and Mozilla is currently worthwhile.   If
> your using them for security, set up your own internal CA with a couple of
> roots and issue certs for your own usage.  It's more secure because then
> YOU are the one who decided to trust the CA.  Moreover, it is more secure
> because YOU can set much shorter expiration[why wait a whole year?  Expire
> it in a month and generate a new one!] so if a cert is stolen it will
> expire soon - and YOU can revoke certificates that are being used
> fraudulently.
>
> The only benefit to purchasing an SSL Certificate is marketing. There are
> a few people who will choose not to purchase a product if the SSL
> Certificate doesn't "look right".  However, considering the large number of
> active e-commerce websites taking orders today using expired certificates -
> I think the number of sales lost is minimal.
>
> I do see a purpose to trusted third parties - it is just the current
> system which is flawed.
> _______________________________________________
> New York PHP User Group Community Talk Mailing List
> http://lists.nyphp.org/mailman/listinfo/talk
>
> http://www.nyphp.org/show-participation
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20131203/fb2e8501/attachment.html>

From garyamort at gmail.com  Wed Dec  4 15:26:39 2013
From: garyamort at gmail.com (Gary A. Mort)
Date: Wed, 04 Dec 2013 15:26:39 -0500
Subject: [nycphp-talk] Why do unit tests not inherit?
In-Reply-To: <001d01ceee23$a113d2a0$e33b77e0$@tutteli.ch>
References: <52863D40.1000105@gmail.com>	<2E4E4B64-EFB1-4E1D-BF0D-BC80C5DEF761@gmail.com>	<000b01cee21b$90d8e150$b28aa3f0$@tutteli.ch>	<5286588B.2090108@gmail.com>	<001601cee22c$364ae740$a2e0b5c0$@tutteli.ch>	<528FB463.6010009@gmail.com>
	<001d01ceee23$a113d2a0$e33b77e0$@tutteli.ch>
Message-ID: <529F8FFF.7000801@gmail.com>

On 11/30/2013 06:26 PM, Robert Stoll wrote:
> I am glad you coming back to me with this, I find it to be a very interesting topic
>
>> -----Original Message-----
>> From: talk-bounces at lists.nyphp.org [mailto:talk-bounces at lists.nyphp.org] On Behalf Of Gary A. Mort
>> Sent: Friday, November 22, 2013 8:46 PM
>> To: NYPHP Talk
>> Subject: Re: [nycphp-talk] Why do unit tests not inherit?
>>
>> Thanks Robert...  I may be misunderstanding something here:
>>
>> On 11/15/2013 12:57 PM, Robert Stoll wrote:
>>> I am not sure if we talk about the same. Just to avoid misunderstands I am going to outline a little bit more what I
>>> meant. I did not mean that each method of a class has to have its one test class. But each method of a class A
> should
>>> have an own test method in the test class T. And if the method of class A has branches, let's say one if-statement,
> then
>>> the ideal case would be that you create two test methods in C which covers both cases. Once for the case that the
>>> if-condition evaluates to true and once to false.
>>> For example:
>>>
>>> class A{
>>>       private $_isActive=false;
>>>       function isActive(){
>>>           return $this->_isActive;
>>>       }
>>>       function foo(){
>>>           $this->_isActive=true;
>>>       }
>>>
>>>       function bar(){
>>>           if($isActive){
>>>               doesThis();
>>>           } else{
>>>               doesThat();
>>>           }
>>>       }
>>> }
>>>
>>> class T extends SomeTestFramework{
>>>       public function testFoo_Standard_IsActiveSetToTrue (){
>>>           // arrange
>>>           // act
>>>           // assert
>>>       }
>>>       public function testBar_IsActiveIsTrue_DoesThis(){}
>> I am assuming that there is no unit testing magic which is setting
>> things, so this method would actually be:
>>
>> public function testBar_IsActiveIsTrue_DoesThis(){
>>
>> // create an object $testObject of class A
>> // call $testObject->foo() to make it active
>> // Test that $testObject->isActive returns true
>> // Test that $testObject->bar executes doesThis()
>>
>> }
>>
>>
>> public function testBar_IsActiveIsFalse_DoesThat(){
>>
>> // create an object $testObject of class A
>> // Test that $testObject->isActive returns false
>> // Test that $testObject->bar executes doesThat()
>>
>> }
> [Robert Stoll]
> That right, that's how my tests would look like more or less with the slight difference that I would not test if
> isActive is true or false (I would cover it in another test case) but it's ok to test that as well.
>
>> It's with the above commented steps that I have an issue.  Primarily
>> because in practice, if someone creates:
>>
>> Class APrime extend A{}
>>
>> Then they also create
>>
>> class TPrime extends SomeTestFramework{
>>
>>       function bar(){
>>           if($isActive){
>>               doesThis();
>>           } else{
>>               doesNOTDOThat();
>>           }
>>
>> }
> [Robert Stoll]
> I guess you made a mistake, the new behaviour should be in APrime (as in the next paragraph) and not in TPrime:
> class APrime extend A{
>      function bar(){
>          if($isActive){
>              doesThis();
>          } else{
>              doesNOTDOThat();
>          }
> }
>
>> In in TPrime will be:
>>
>>
>> public function testBar_IsActiveIsTrue_DoesThis(){
>>
>> // create an object $testObject of class APrime
>> // call $testObject->foo() to make it active
>> // Test that $testObject->isActive returns true
>> // Test that $testObject->bar executes doesThis()
>>
>> }
>>
>>
>> public function testBar_IsActiveIsFalse_DoesNOTDOThat(){
>>
>> // create an object $testObject of class APrime
>> // Test that $testObject->isActive returns false
>> // Test that $testObject->bar executes doesNOTDOThat()
>>
>> }
>>
>> So everything has been cut and pasted from one to the other.  The only
>> difference is that APrime calls doesNOTDOThat instead of doesThat.
>> Testing items where taken from one to the other, with minor editing
>> changes to half of the new tests to change doesThat to doesNOTDOThat
> [Robert Stoll]
> I agree, but first of all the question arises, does APrime not already break the Liskov Substitution Principle by
> invoking a different method (doesNOTDOThat instead of doesThat)?


Mostly the situation I was trying to describe but not get into nitty 
details are situations where you have external dependencies.

Take storing data to a cache of some sort as a really good example.

The lifecycle of a cache engine could be:
1) Abstact CacheEngine class where you define an isSupported method 
which will always return false since you can't store items in the 
abstract class.  [Yes, with PHP 5.4+ this would instead be better 
defined as an interface, but we can't all refuse to support 5.3. :-)]

2) A child class, CacheEngineMemcache where you can run some check to 
see if Memcache works[on my mind mainly because I just had to create a 
new class for this in Joomla, CacheEngineGaeMemcache because the Joomla 
platform checks to see if the Memcache extension is loaded AND the 
Memcache class exists in it's implementation. Google happens to provide 
both free and paid usage of Memcache for Google App Engine - but they 
don't use the PHP Memcache extension, the code is included in their GAE 
extension to interface with their setup.]

3) A third child class, CacheEngineMemcached which since it shares 90% 
of the same code as Memcache, subclasses CacheEngineMemcache but 
modifies isSupported to check for Memcached instead.


So you have 3 classes each implementing the same method[isSupported] 
which will return either true or false depending on some underlying 
configuration.   Using various PHP extensions it's possible to 
dynamically load/unload the extension so you can confirm your tests - as 
long as isSupported always returns true and false.


Things get extended, changed, modified beyond belief.  Some day for some 
reason, someone may decide that for their engine, they may return 3 
instead of TRUE for isSupported under some odd situation - maybe to 
indicate the version of something being supported.  Due to the beautiful 
nature of PHP, when doing simple true/false checks 3 will show up as 
true, so it is a very easy way to be backwardly compatible and add some 
extra function.


One answer is, of course, "well, that was a bad design decision.  I 
don't see any reason to design unit tests to prevent bad design decisions."

But to me, the entire point of unit tests IS to prevent compatibility 
issues, re-introduction of bugs, etc.  The whole point of programming in 
PHP is that PHP programmers are free to code things any way we want 
because PHP doesn't have strict typing and all that other stuff.  It's 
made to do fast, fun coding and serious coding - so it allows college 
kids to create things like Facebook as a fun, riddled with holes 
project, and then refine it when it becomes popular - and it allows one 
to establish a coding discipline inside a company to maintain that 
insanely popular franchise.

 From what I see with unit testing in practice[open source projects], 
there is an assumption that the fixed coding structure is going to be 
followed - and so what actually occurs is that unit tests are only 
useful for 2-3 years, 5 years at most.  At that point, there will be 
some new "cool" design pattern that everyone will be switching 
to[because it's fun...not because it is "good coding practice"] and all 
that "old ugly code" will get bent to fit the new practice and the unit 
tests don't help much to discover the problems.

Hmm, rambling out loud so I'll end it there....  it's more meta design 
than anything else...  I think part of my issue is I have a different 
viewpoint then most programmers.  I don't tend to come into a project 
and say "you need to throw out all this old code and do things the new 
one true way", I try to integrate things.  When you integrate, you see 
problems where design patterns shifted and while a unit test could have 
detected it - they weren't written to do so.

Whereas if you can restrict a project to a common framework where 
everything works the same way, and the way you want - then it doesn't 
make sense to have tests to check to see if things are still following 
that pattern - everyone follows that pattern or they aren't on the team.

Both are valid approaches...the latter is a lot easier to extend and 
maintain - but it's a lot more expensive to implement[especially with 
company mergers where you have to throw away all the IT infrastructure 
of one company to be on a common platform].

Whereas integration can lead to a maintenance nightmare in the long run 
- but it keeps the budget down in the short run and avoids spending 
large sums of money on exploratory projects which may get cancelled.

From garyamort at gmail.com  Thu Dec  5 20:32:06 2013
From: garyamort at gmail.com (Gary A. Mort)
Date: Thu, 05 Dec 2013 20:32:06 -0500
Subject: [nycphp-talk] Google App Engine best practices links?
Message-ID: <52A12916.4010906@gmail.com>

I was wondering if there are any best practice web sites on using PHP on 
Google App Engine.

While working through installing the Joomla! CMS on GAE I've run into 
some weird oddities and initially have taken a rather brute force 
approach to work through them.

Being unhappy with the brute force method[which requires modifying core 
files in the open source code in order to accommodate GAE] I have 
continued to cycle on it in the back burner and am trying an alternate 
approach right now.

Specifically, in Joomla there are 3 main entree points to an application:
http://mydomain.com/index.php
http://mydomain.com/administrator/index.php
http://mydomain.com/installation/index.php


So far I've run into 2 issues:
1) Joomla uses XML files in order to define html form's.  PHP is used to 
parse those files and then build the forms.  GAE disables the ability to 
load /remote/ XML files in PHP by default.  It is possible to allow this 
by add libxml_disable_entity_loader to the list of enabled functions and 
then to call libxml_disable_entity_loader(false); at some point in the 
code.  For some reason, despite the fact that these are LOCAL xml files 
Jooma attempts to read, I still need to use this fix to allow Joomla to 
read the local files.

2) Joomla defaults to saving sessions in files, GAE defaults to saving 
sessions in memcache.  Attempt to save session files using the default 
save_path does not work since the path does not exist.  Making a small 
hack to make memcache the default does not work because Joomla checks 
for the existence of the Memcache extension[via extension_loaded()] 
which does not exist in GAE.   A slightly more involved solution 
required me adding a new GaeMemcache class to override that check, and 
modifying a core class to force it to enable GaeMemcache.

None of this is bad...it's just inelegant and messy.

It strikes me that this was the wrong way to go about it.  Because of 
the way GAE is configured through app.yaml to match URI patterns to 
individual php files - instead of changing the core code, I can instead 
provide a pre-loader to process the file.

So my new file structure will be as follows:
/gae/joomla-site.php
/gae/joomla-install.php
/gae/joomla-admin.php
/gae/lib/gaememcache.php
/gae/appl.yaml
/joomla-cms : submodule git repository pointer for the Joomla-CMS repository


With this layout, I can now define my 3 entree points so that instead of 
loading the various index.php files directly, I can proxy the call first 
by the /gae/joomla* php file.  That gives me the ability to make any 
Google App Engine modifications needed[defining a special memcache 
handler for GAE, making my libxml_disable_entity_loader function call - 
etc.  No core hacks needed - now I can just setup a special 
pre-processors to handle everything.

The configuration ability of GAE is extremely fascinating..  In many 
ways it is overly cumbersome for simply usage due to the options 
available - but the options also allow for neat little workarounds[I 
also realized that instead of hacking the core file, I could have made a 
copy of the core file under my gae directory and used the upload path 
overrides to overwrite the core files only when uploaded/deployed to GAE]

What I am somewhat curious about is if there are any best practices 
tutorials out there since this sort of situation seems like it should be 
common, and the various answers are intuitive once you start groking the 
GAE deployment system.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20131205/1960d161/attachment.html>

From rstoll at tutteli.ch  Tue Dec 10 05:59:18 2013
From: rstoll at tutteli.ch (Robert Stoll)
Date: Tue, 10 Dec 2013 11:59:18 +0100
Subject: [nycphp-talk] Why do unit tests not inherit?
In-Reply-To: <529F8FFF.7000801@gmail.com>
References: <52863D40.1000105@gmail.com>	<2E4E4B64-EFB1-4E1D-BF0D-BC80C5DEF761@gmail.com>	<000b01cee21b$90d8e150$b28aa3f0$@tutteli.ch>	<5286588B.2090108@gmail.com>	<001601cee22c$364ae740$a2e0b5c0$@tutteli.ch>	<528FB463.6010009@gmail.com>	<001d01ceee23$a113d2a0$e33b77e0$@tutteli.ch>
	<529F8FFF.7000801@gmail.com>
Message-ID: <001301cef596$e02b80d0$a0828270$@tutteli.ch>


> -----Original Message-----
> From: talk-bounces at lists.nyphp.org [mailto:talk-bounces at lists.nyphp.org] On Behalf Of Gary A. Mort
> Sent: Wednesday, December 04, 2013 9:27 PM
> To: talk at lists.nyphp.org
> Subject: Re: [nycphp-talk] Why do unit tests not inherit?
> 
> 
> Mostly the situation I was trying to describe but not get into nitty
> details are situations where you have external dependencies.
> 
> Take storing data to a cache of some sort as a really good example.
> 
> The lifecycle of a cache engine could be:
> 1) Abstact CacheEngine class where you define an isSupported method
> which will always return false since you can't store items in the
> abstract class.  [Yes, with PHP 5.4+ this would instead be better
> defined as an interface, but we can't all refuse to support 5.3. :-)]
> 
> 2) A child class, CacheEngineMemcache where you can run some check to
> see if Memcache works[on my mind mainly because I just had to create a
> new class for this in Joomla, CacheEngineGaeMemcache because the Joomla
> platform checks to see if the Memcache extension is loaded AND the
> Memcache class exists in it's implementation. Google happens to provide
> both free and paid usage of Memcache for Google App Engine - but they
> don't use the PHP Memcache extension, the code is included in their GAE
> extension to interface with their setup.]
> 
> 3) A third child class, CacheEngineMemcached which since it shares 90%
> of the same code as Memcache, subclasses CacheEngineMemcache but
> modifies isSupported to check for Memcached instead.
> 
> 
> So you have 3 classes each implementing the same method[isSupported]
> which will return either true or false depending on some underlying
> configuration.   Using various PHP extensions it's possible to
> dynamically load/unload the extension so you can confirm your tests - as
> long as isSupported always returns true and false.
> 
> 
> Things get extended, changed, modified beyond belief.  Some day for some
> reason, someone may decide that for their engine, they may return 3
> instead of TRUE for isSupported under some odd situation - maybe to
> indicate the version of something being supported.  Due to the beautiful
> nature of PHP, when doing simple true/false checks 3 will show up as
> true, so it is a very easy way to be backwardly compatible and add some
> extra function.
> 
> 
> One answer is, of course, "well, that was a bad design decision.  I
> don't see any reason to design unit tests to prevent bad design decisions."
> 

My approach works only for own code/libraries/frameworks and theoretically for third party test code which was written
with extensibility in mind. But to be honest, I think I have never written whole unit-tests suites against third party
code. I have written sometimes a few simple unit-tests just to figure out how the third party library works but that was
it.

If I really create a sub-class of a third party class (most of the time I chose aggregation or composition instead) then
I would test every method and wouldn't really bother whether the third party code has its own tests or not (along the
lines of "trust is good, control is better").

I think writing unit test with extensibility of the test code itself in mind is not yet a best practice and I for myself
started writing unit tests this way no longer than a year ago. If extensibility of test code should become a best
practice then I might stick to my approach and go more often for sub-classes of third party code where appropriate.

Cheers,
Robert



From ron at vnetworx.net  Tue Dec 17 18:14:06 2013
From: ron at vnetworx.net (Ron Guerin)
Date: Tue, 17 Dec 2013 18:14:06 -0500
Subject: [nycphp-talk] Prevalence of bcmath (new look)
Message-ID: <52B0DABE.2060205@vnetworx.net>

Had a moment of deja vu over the weekend, wondering about the prevalance
of bcmath and then remembering I'd asked that here about three years ago:

http://www.nyphp.org/list/talk-295-common-is-bcmath

Daniel Convissor wrote:
> Hey Ron:
>
>
>> I'm looking at using some code that uses the bcmath extension. How
>> likely is it that a user is going to have hosting without bcmath in
>> their PHP?
>>
>
> Crude survey via Google...
>
> phpinfo -bcmath = 4 million hits
> phpinfo +bcmath = 200 k hits

Current crude survey via Google...

About 2,630,000 results for: phpinfo googlebot -bcmath
About 1,130,000 results for: phpinfo googlebot +bcmath

I had to change the search a bit, based on:
http://blog.securitee.org/?p=18

... because today I get a paltry 7 results for "phpinfo +bcmath", the
first of which is an archive of this list, and the second a mirror of
the archive of this list.

While you can't really compare the old searches to the new ones much, I
think it's still safe to say that bcmath is not reliably available,
which is what I was and am still concerned about.  Luckily, there's
always Math_BigInteger.

- Ron

-- 
Join the NY Metro Area Tech Discussion!
http://lists.luny.org/mailman/listinfo/talk

From garyamort at gmail.com  Mon Dec 30 17:00:41 2013
From: garyamort at gmail.com (Gary A. Mort)
Date: Mon, 30 Dec 2013 17:00:41 -0500
Subject: [nycphp-talk] How to invoke stream_cast method?
Message-ID: <52C1ED09.8070100@gmail.com>

Short question:
The stream_cast method has thrown me for a loop.  The method does not 
take any parameters and is invoked by stream_select which has lots of 
arguements - so I don't know what I'm supposed to return for it and 
where to get the options....  I figured I'd ask here if anyone else 
knows what they are.

-----Long explanation------
I've been hacking about with Google's App Engine and Joomla.  One 
limitation I ran into is that App Engine does not allow for the PHP 
application running on the website to change/modify/add files to a 
running application.   In essence, from within a PHP application running 
on App Engine[or any other language for that matter] we only have "read" 
access to the file system.

Benefits of this are of course, security[no exploits can be used to 
modify php scripts on the website] - performance[static resources such 
as javascript, images, css, etc can be optimized for delivery] and 
caching[since the files are only modified when new code is 'deployed' 
APC does not need to check the file change dates when caching PHP code - 
the deployment process can force a flush of the cache when needed].

App Engine does allow for accessing files from Google Cloud Storage 
buckets - and they even provide a stream wrapper so any gs://bucketname 
paths can be treated like files.  You can even allow for execution of 
PHP code from Cloud Storage....but then your no longer secure from 
exploits which try to modify PHP files on the server!]

For my own custom code, it's easy enough to build paths using different 
paths.  IE when checking to include php scripts with file_exists I can 
use the local file: path - and when saving or retrieiving image file 
uploads I can use the gs: file path.   But to get someone else's code 
working that way is a non-trivial chunk of work - and it struck me that 
instead I can let PHP do things "magically".  So I created my own stream 
wrapper:https://github.com/garyamort/Stream-Morpher 
<https://github.com/garyamort/Stream-Morpher>

It can use a set of string manipulation rules to convert one path to 
another, ie
ggsm://websitepath/media/image.png would become 
gs://gmimagebucket/images/image.png and a default rule at the end can 
swap ggsm://websitepath/anythingelse to file:///appinstancepath/anythingelse

For the most part, it's been fairly obvious how to map to method calls.  
Most file modifications will only be made after a call to fopen, so 
stream_open is the primary method:
         $this->streamHandle = false;
         if ($this->processPathname($pathname, $mode))
         {
             if ($this->checkRecursiveRules($this->path, 
STREAM_URL_STAT_QUIET))
             {
                 // Path translated to itself recursively, abort, abort
                 $this->path = null;
                 return false;
             }
              $use_include_path = $options & STREAM_USE_PATH;

             $handle = fopen($this->path->truePath, $mode, 
$use_include_path);
             if (is_resource($handle))
             {
                 $this->streamHandle = $handle;
                 return true;
             }

         }
         return false;


That code converts the pathname to the "true" pathname, makes sure that 
whatever stream it morphed into is not assigned to the stream morpher 
itself[otherwise you get ugly recursion calls as it tries to keep 
morphing it over and over],  and finally simply calls fopen again to 
pass the file open on to the real processor.

One oddity I found is that the return from stream_open is irrelevant, I 
originally tried returning the handle opened however future calls to 
read and write would use my morpher object, not the handle - so I had to 
save the "true" handle in the morpher object and create a proxy call for 
every method.  Some of them, such as write, are simple:
     function stream_write($data)
     {
         return fwrite($this->streamHandle, $data);
     }


Some them are ugly due to having to check lots of flags, such as set_option:
     public function stream_set_option ( $option , $arg1 , $arg2 )
     {
         if ($option & STREAM_OPTION_BLOCKING)
         {
             return stream_set_blocking($arg1, $arg2);
         }


         if ($option & STREAM_OPTION_READ_TIMEOUT)
         {
             return stream_set_timeout($arg1, $arg2);
         }


         if ($option & STREAM_OPTION_WRITE_BUFFER)
         {
             return stream_set_write_buffer($arg1, $arg2);
         }

         return false;

     }


But stream_cast has thrown me for a loop.  The method does not take any 
parameters and is invoked by stream_select which has lots of arguements 
- so I don't know what I'm supposed to return for it and where to get 
the options....  I figured I'd ask here if anyone else knows what they are.


I'm still hacking around a bit on the driver to use it for other 
things.  For example, since the mode a file is opened with is known, it 
would be possible to use the regular file stream wrapper for files 
opened in read mode, but use an ftp wrapper for files opened in write mode.

Or for things like logfile writing, since their usually a sequence of 
lines appended to a file, modify log file paths so writes get sent to 
syslog of phperror instead.

--Gary
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20131230/dc71b2d2/attachment.html>