Re: [PHP-DOC] streams reference
Wez- Wow! Thanks for the voluminous descriptions! I'll print this out and read it in more detail on the train ride home tonight. -Pollita -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DOC] streams reference
Hi Sara, Thanks for making a start on this. Just a couple of things to note about streams: A "stream" is an object that exhibits "streamable" behaviour. A "wrapper" is additional logic that knows about specific protocols (and encodings) and returns an appropriate stream to access it. A wrapper may modify certain aspects of a streams behaviour. It's quite a common misconception that a stream == a wrapper. So, stream_get_wrappers() lists the registered handlers for specific protocol schemes; this is not the same a listing the types of streams that are available (file, network, zlib, bzip2). There is currently no way to retrieve information about the latter. You can also implement wrapper functions to handle opendir() and readdir() for your schemes in your wrapper class (for stream_register_wrapper()). I gave an explanation of this on php-dev at that time (iirc); user_streams.c 1.24: Sat Sep 28 09:05:47 2002 filters can be defined in C code as well as PHP scripts; there is a "string.rot13" filter implementation written in C included in PHP 4.3.0. So it is important to note in stream_filter_(prepend|append) that extension defined filters can also be used (and not just those registered with stream_register_filter). $filter->oncreate() is called just after the filter object is instantiated, but before it is connected to a stream. It's purpose is to perform any early initialization for the filter based on $filter->params and $filter->filtername which correspond to the appropriately named parameters for stream_filter_(prepend|append). The filtername is (potentially) important because filters can be registered using a pattern (so one class handles a range of filter names). Yes, using a factory class might be a better approach, and I may yet alter the user-filter architecture in this way. It is important to note that a filter instance is reponsible for managing any buffers it requires for data passing through it. $filter->write($data) should return the number of bytes of $data that it consumed, even if the number of bytes that were passed on to the next filter in the chain (via parent::write()) are different. This is important because the return value indicates to the caller (either fread() or an earlier filter) how far to advance its buffer pointer. $filter->write() is allowed to buffer the data internally (and not call parent::write()), provided that it returns the number of bytes of the input it used to create that buffer. Obviously, it needs to be consistent and send that data on to the next filter at the appropriate time (when enough data are accumulated, or $filter->flush() is called). Likewise, $filter->read($size) is welcome to call parent::read() with a larger $size, provided that it maintains its buffers correctly. It is an error for $filter->read() to return more bytes than requested. $filter->onclose() is called during filter shutdown. It is called after $filter->flush(true) is called and it's purpose is to release any resources that were opened by this filter instance. Yes, stream contexts are very thinly documented. That's mostly because you can't do very much with them ATM. There is an open bug report with a reasonable amount of information about them (search the DB); if you feel like integrating that info, I will gladly edit it to make sure it is correct; otherwise, I'm quite happy to delay documenting this in much more detail until there are more things that make it worthwhile (because it's one of those "so-what?" features ATM). --Wez. On Sat, 4 Jan 2003, Sara Golemon wrote: > Okay, > > An initial draft of the streams reference is in CVS documenting all 14 > stream_* functions and providing three examples on the reference page. > While we all wait ((*snore*)) for php.net/manual/en to build, I've got a > local build available on my devbox: > http://169.229.139.97/phpdoc/html/current/ref.stream.html > > Note: There are a couple minor changes on ref.stream which havn't shown on > my local build yet (see r1.4), a new build is running now. > > The documentation on stream contexts is VERY thin as I frankly don't > understand how they work entirely. stream-register-filter.xml also needs > a description of what the oncreate/onclose methods do (I've asked wez in a > somewhat unrelated bug report to explain those). > > Any comments/suggestions would, as always, be appreciated. > > Happy New Year! > > -Pollita > > > > -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DOC] streams reference
It's really a big and nice work. Thank you Pollita and Happy new year since I've not seen you on IRC. -- Regards. M.CHAILLAN Nicolas [EMAIL PROTECTED] www.WorldAKT.com Hébergement de sites internets. "Sara Golemon" <[EMAIL PROTECTED]> a écrit dans le message de news: [EMAIL PROTECTED] > Okay, > > An initial draft of the streams reference is in CVS documenting all 14 > stream_* functions and providing three examples on the reference page. > While we all wait ((*snore*)) for php.net/manual/en to build, I've got a > local build available on my devbox: > http://169.229.139.97/phpdoc/html/current/ref.stream.html > > Note: There are a couple minor changes on ref.stream which havn't shown on > my local build yet (see r1.4), a new build is running now. > > The documentation on stream contexts is VERY thin as I frankly don't > understand how they work entirely. stream-register-filter.xml also needs > a description of what the oncreate/onclose methods do (I've asked wez in a > somewhat unrelated bug report to explain those). > > Any comments/suggestions would, as always, be appreciated. > > Happy New Year! > > -Pollita > > -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DOC] streams reference
Okay, An initial draft of the streams reference is in CVS documenting all 14 stream_* functions and providing three examples on the reference page. While we all wait ((*snore*)) for php.net/manual/en to build, I've got a local build available on my devbox: http://169.229.139.97/phpdoc/html/current/ref.stream.html Note: There are a couple minor changes on ref.stream which havn't shown on my local build yet (see r1.4), a new build is running now. The documentation on stream contexts is VERY thin as I frankly don't understand how they work entirely. stream-register-filter.xml also needs a description of what the oncreate/onclose methods do (I've asked wez in a somewhat unrelated bug report to explain those). Any comments/suggestions would, as always, be appreciated. Happy New Year! -Pollita -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DOC] streams reference
On Fri, 3 Jan 2003, Wez Furlong wrote: > http://www.php.net/manual/en/function.fopen.php > > "Note: The list of supported protocols can be found in Appendix I. " > > Appendix I is a link... OOPS, I was looking through streams API docs and not wrappers.xml :) This is fine and not part of streams api docs, doh! My bad! Regards, Philip -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DOC] streams reference
http://www.php.net/manual/en/function.fopen.php "Note: The list of supported protocols can be found in Appendix I. " Appendix I is a link... --Wez. On Fri, 3 Jan 2003, Philip Olson wrote: > On Fri, 3 Jan 2003, Wez Furlong wrote: > > Do you volunteer to maintain 2 * (number of translations) of the > > information about which streams/wrappers are present? > > Users are not expected to read the entire documentation > of PHP streams API just to get some information on how > to use the PHP functions found in ref.stream This is > especially true when this information is moved into the > developers manual later on. > > Also, my comments below are more general then this > specific topic of available streams. And besides, I > can't find this information in the appendix so please > point me to it. > > > That is the reason that I moved the wrapper information into an > > appendix, because it made reading about this stuff difficult (and the > > fopen() reference page unreadable). > > Which is why ref.stream now exists. A place where your > typical PHP user can learn how to use streams, not a > place to learn how to implement streams into PHP > extensions. > > Regards, > Philip > > > > > On Fri, 3 Jan 2003, Philip Olson wrote: > > > > > > > When are certain streams not available, like, I assume > > > > > allow_url_fopen dictates the availability of the http stream? > > > > > FTP module for ftp, etc. > > > > > > > > > This is all documented in Apendix I (which is linked a couple times from > > > > ref.stream), do you think we need to go into it in detail on ref.stream as > > > > well? > > > > > > I'm struggling with a response to this but in the end > > > I feel the answer is yes. Here's why: > > > > > > a) Users should never be expected to read about > > >the streams API much like users are never > > >expected to understand PHP source. > > > b) This only adds to the confusion on which functions > > >are PHP functions and which are part of the > > >API. > > > c) One day there will be a PHP developers manual > > >and I assume the streams API docs will be > > >moved as part of it. So the less we rely on > > >them now the better. > > > > > > Also, I am unable to find this information in the appendix. > > > > > > Basically, ref.stream should hold its own and streams api > > > should only be an enhancement of knowledge for advanced > > > users, such as PHP source developers. > > > > > > Regards, > > > Philip > > > > > > > > > > > > > > > -- > > PHP Documentation Mailing List (http://www.php.net/) > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > > > -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DOC] streams reference
> Do you volunteer to maintain 2 * (number of translations) of the > information about which streams/wrappers are present? > > That is the reason that I moved the wrapper information into an > appendix, because it made reading about this stuff difficult (and the > fopen() reference page unreadable). We discussed creating the "PHP Developers Manual" sometime in the future, and also discussed that it should be English only. So when it is started (maybe in a 'dev' subdir of phpdoc for start?), all the translations of the non userspace stuff will be useless (not built for the online manual). Therefore I recommend adding a note to the API docs XML file that there is not too much point in translating that. Unless there is a good point to support translation of the developers manual, in which case I'll go completely mad ;) Goba -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DOC] streams reference
On Fri, 3 Jan 2003, Wez Furlong wrote: > Do you volunteer to maintain 2 * (number of translations) of the > information about which streams/wrappers are present? Users are not expected to read the entire documentation of PHP streams API just to get some information on how to use the PHP functions found in ref.stream This is especially true when this information is moved into the developers manual later on. Also, my comments below are more general then this specific topic of available streams. And besides, I can't find this information in the appendix so please point me to it. > That is the reason that I moved the wrapper information into an > appendix, because it made reading about this stuff difficult (and the > fopen() reference page unreadable). Which is why ref.stream now exists. A place where your typical PHP user can learn how to use streams, not a place to learn how to implement streams into PHP extensions. Regards, Philip > On Fri, 3 Jan 2003, Philip Olson wrote: > > > > > When are certain streams not available, like, I assume > > > > allow_url_fopen dictates the availability of the http stream? > > > > FTP module for ftp, etc. > > > > > > > This is all documented in Apendix I (which is linked a couple times from > > > ref.stream), do you think we need to go into it in detail on ref.stream as > > > well? > > > > I'm struggling with a response to this but in the end > > I feel the answer is yes. Here's why: > > > > a) Users should never be expected to read about > >the streams API much like users are never > >expected to understand PHP source. > > b) This only adds to the confusion on which functions > >are PHP functions and which are part of the > >API. > > c) One day there will be a PHP developers manual > >and I assume the streams API docs will be > >moved as part of it. So the less we rely on > >them now the better. > > > > Also, I am unable to find this information in the appendix. > > > > Basically, ref.stream should hold its own and streams api > > should only be an enhancement of knowledge for advanced > > users, such as PHP source developers. > > > > Regards, > > Philip > > > > > > > > > -- > PHP Documentation Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DOC] streams reference
Do you volunteer to maintain 2 * (number of translations) of the information about which streams/wrappers are present? That is the reason that I moved the wrapper information into an appendix, because it made reading about this stuff difficult (and the fopen() reference page unreadable). --Wez. On Fri, 3 Jan 2003, Philip Olson wrote: > > > When are certain streams not available, like, I assume > > > allow_url_fopen dictates the availability of the http stream? > > > FTP module for ftp, etc. > > > > > This is all documented in Apendix I (which is linked a couple times from > > ref.stream), do you think we need to go into it in detail on ref.stream as > > well? > > I'm struggling with a response to this but in the end > I feel the answer is yes. Here's why: > > a) Users should never be expected to read about >the streams API much like users are never >expected to understand PHP source. > b) This only adds to the confusion on which functions >are PHP functions and which are part of the >API. > c) One day there will be a PHP developers manual >and I assume the streams API docs will be >moved as part of it. So the less we rely on >them now the better. > > Also, I am unable to find this information in the appendix. > > Basically, ref.stream should hold its own and streams api > should only be an enhancement of knowledge for advanced > users, such as PHP source developers. > > Regards, > Philip > > > -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DOC] streams reference
> > When are certain streams not available, like, I assume > > allow_url_fopen dictates the availability of the http stream? > > FTP module for ftp, etc. > > > This is all documented in Apendix I (which is linked a couple times from > ref.stream), do you think we need to go into it in detail on ref.stream as > well? I'm struggling with a response to this but in the end I feel the answer is yes. Here's why: a) Users should never be expected to read about the streams API much like users are never expected to understand PHP source. b) This only adds to the confusion on which functions are PHP functions and which are part of the API. c) One day there will be a PHP developers manual and I assume the streams API docs will be moved as part of it. So the less we rely on them now the better. Also, I am unable to find this information in the appendix. Basically, ref.stream should hold its own and streams api should only be an enhancement of knowledge for advanced users, such as PHP source developers. Regards, Philip -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DOC] streams reference
>--Cross-Post from php-doc discussion thread-- > > You may want to mention what the following means, this is > from a phpinfo() on www.php.net: > > Registered PHP Streams: http > php > ftp > https > compress.zlib > I mention using phpinfo() to see what wrappers are available, but not detail on all the builtin streams. I've got references (w/ links) to Apendix I for that. > Is there a function to get this specific information? Would > that be useful? Maybe something like get_registered_streams(). > That does sound like it'd be useful... Unfortunately there isn't a userland function for that. There *IS* however, a PHPAPI call for it: PHPAPI HashTable *php_stream_get_url_stream_wrappers_hash(); It wouldn't take much to make a userland wrapper for it since it already returns a hash table... stream_get_wrappers(); sounds like an appropriate name > When are certain streams not available, like, I assume > allow_url_fopen dictates the availability of the http stream? > FTP module for ftp, etc. > This is all documented in Apendix I (which is linked a couple times from ref.stream), do you think we need to go into it in detail on ref.stream as well? -Pollita Cross posting to php-dev re: addition of stream_get_wrappers() addition. -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DOC] streams reference
You may want to mention what the following means, this is from a phpinfo() on www.php.net: Registered PHP Streams: http php ftp https compress.zlib Is there a function to get this specific information? Would that be useful? Maybe something like get_registered_streams(). When are certain streams not available, like, I assume allow_url_fopen dictates the availability of the http stream? FTP module for ftp, etc. Anyway, something else to consider in case you haven't yet :) Regards, Philip -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DOC] streams reference
> Please make that dir stream not streams as to make > the shortcuts nicer for api vs function reference. > Half a step ahead of ya... ./en/reference/stream/reference.xml ./en/reference/stream/functions/stream-get-meta-data.xml ./en/reference/stream/functions/stream-register-wrapper.xml ./en/reference/stream/functions/stream-set-blocking.xml ./en/reference/stream/functions/stream-set-timeout.xml ./en/reference/stream/functions/stream-set-write-buffer.xml My documentation of filters is going to be limited to start with, for the moment I want to get *something* in place. I'll be fleshing out the reference.xml page with filter documentation and adding the other stream_* functions tomorrow and over the weekend. I'll also have the x-links between the API and the userland pages in place by tonight. -Pollita (forgot to run ./configure last time now to start that build again) -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DOC] streams reference
> Yup, as I mentioned pollita on #php, a new dir > "en/reference/streams" would be the best way to go. > > +1 for that addition. Please make that dir stream not streams as to make the shortcuts nicer for api vs function reference. Regards, Philip -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DOC] streams reference
> A major benefit of this new section will be having its > own large introduction. This is much needed as it needs > to be wordy, and include examples and comparisons of a > few other "alternative/older" methods. > > I do not volunteer doing this as I don't understand the > topic of streams yet but I do look forward to these docs, > please put them in laymens terms ;) > I've got a draft of stream/reference.xml already and am just doing the make now to take a look at it in a browser. Once I have something that works I'll commit the changes to create the stream section in the reference, move the existing function definitions over, and add the reference.xml page itself. Once that's all in place, we can improve on the wording in reference.xml and add the additional documentation pages in stream/functions. -Pollita -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DOC] streams reference
--- Derick Rethans <[EMAIL PROTECTED]> wrote: > On Thu, 2 Jan 2003, Gabor Hojtsy wrote: > > > > Actually, turns out: > > > stream_get_meta_data > > > stream_register_wrapper > > > stream_set_blocking > > > stream_set_timeout > > > stream_set_write_buffer > > > > > > ARE in the manual under the filesystem section. > Should the missing > > > functions be added in there? Or still go ahead > with creating a new streams > > > section and move these guys over? > > > > IMHO, it should be a new streams section. Streams > are used by many > > other things, not just file functions (eg. > include/require). > > I would favor that too. Yup, as I mentioned pollita on #php, a new dir "en/reference/streams" would be the best way to go. +1 for that addition. = --- Jesus M. Castagnetto <[EMAIL PROTECTED]> __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DOC] streams reference
On Thu, 2 Jan 2003, Derick Rethans wrote: > On Thu, 2 Jan 2003, Gabor Hojtsy wrote: > > > > Actually, turns out: > > > stream_get_meta_data > > > stream_register_wrapper > > > stream_set_blocking > > > stream_set_timeout > > > stream_set_write_buffer > > > > > > ARE in the manual under the filesystem section. Should the missing > > > functions be added in there? Or still go ahead with creating a new streams > > > section and move these guys over? > > > > IMHO, it should be a new streams section. Streams are used by many > > other things, not just file functions (eg. include/require). > > I would favor that too. A major benefit of this new section will be having its own large introduction. This is much needed as it needs to be wordy, and include examples and comparisons of a few other "alternative/older" methods. I do not volunteer doing this as I don't understand the topic of streams yet but I do look forward to these docs, please put them in laymens terms ;) Regards, Philip -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DOC] streams reference
IMHO, since streams have become such an integral part of PHP, it would be best to create a full new section about them, and make links from all other files to the new section... - Tularis Sara Golemon wrote: Sounds appropriate to me. Looks like only streams information exists for dev/api people currently: http://www.php.net/streams So in the end we will have php.net/streams going to the API docs and php.net/stream going to the function reference (ref.stream). Be sure to link each to one another! :) Actually, turns out: stream_get_meta_data stream_register_wrapper stream_set_blocking stream_set_timeout stream_set_write_buffer ARE in the manual under the filesystem section. Should the missing functions be added in there? Or still go ahead with creating a new streams section and move these guys over? -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DOC] streams reference
On Thu, 2 Jan 2003, Gabor Hojtsy wrote: > > Actually, turns out: > > stream_get_meta_data > > stream_register_wrapper > > stream_set_blocking > > stream_set_timeout > > stream_set_write_buffer > > > > ARE in the manual under the filesystem section. Should the missing > > functions be added in there? Or still go ahead with creating a new streams > > section and move these guys over? > > IMHO, it should be a new streams section. Streams are used by many > other things, not just file functions (eg. include/require). I would favor that too. Derick -- - Derick Rethans http://derickrethans.nl/ PHP Magazine - PHP Magazine for Professionals http://php-mag.net/ - -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DOC] streams reference
> Actually, turns out: > stream_get_meta_data > stream_register_wrapper > stream_set_blocking > stream_set_timeout > stream_set_write_buffer > > ARE in the manual under the filesystem section. Should the missing > functions be added in there? Or still go ahead with creating a new streams > section and move these guys over? IMHO, it should be a new streams section. Streams are used by many other things, not just file functions (eg. include/require). Goba -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DOC] streams reference
> > Sounds appropriate to me. Looks like only streams > information exists for dev/api people currently: > > http://www.php.net/streams > > So in the end we will have php.net/streams going to > the API docs and php.net/stream going to the > function reference (ref.stream). Be sure to link > each to one another! :) > Actually, turns out: stream_get_meta_data stream_register_wrapper stream_set_blocking stream_set_timeout stream_set_write_buffer ARE in the manual under the filesystem section. Should the missing functions be added in there? Or still go ahead with creating a new streams section and move these guys over? -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DOC] streams reference
Hi all, maybe little offtopic but strspn() and strcspn() can get additional 2 parameters (starting 4.3.0) I have sent modified xmls to php-doc but was asked for a diff (unified). Unfortunately I cannot provide it. I have also asked for php-doc karma but not received. Philip, may I send the xmls to you? Andrey - Original Message - From: "Philip Olson" <[EMAIL PROTECTED]> To: "Sara Golemon" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Thursday, January 02, 2003 9:26 PM Subject: Re: [PHP-DOC] streams reference > > Sounds appropriate to me. Looks like only streams > information exists for dev/api people currently: > > http://www.php.net/streams > > So in the end we will have php.net/streams going to > the API docs and php.net/stream going to the > function reference (ref.stream). Be sure to link > each to one another! :) > > There are many undocumented functions to document: > > http://zend.com/phpfunc/nodoku.php > > That phpfunc hasn't updated since 4.3.0 but anyway > we have some work to do it seems. :) > > Regards, > Philip > -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DOC] streams reference
Sounds appropriate to me. Looks like only streams information exists for dev/api people currently: http://www.php.net/streams So in the end we will have php.net/streams going to the API docs and php.net/stream going to the function reference (ref.stream). Be sure to link each to one another! :) There are many undocumented functions to document: http://zend.com/phpfunc/nodoku.php That phpfunc hasn't updated since 4.3.0 but anyway we have some work to do it seems. :) Regards, Philip On Thu, 2 Jan 2003, Sara Golemon wrote: > ((A questing in OPN/#php brought up the following issue)) > > So we've got all these streams in php now, but (for all I can tell) no > Streams section in the manual reference. Is anyone working on documenting > these already? Most functions seem to be ported versions of already > existing functions (socket_*, f*, etc...). I'd be happy to start work on > making manual pages for these functions, but I don't want to go all > willy-nilly creating whole new sections in the manual without checking > first. > > A quick rgrep shows the following stream_* functions: > > stream_get_meta_data > stream_select > stream_context_get_options > stream_context_set_option > stream_context_set_params > stream_context_create > stream_filter_prepend > stream_filter_append > stream_set_blocking > stream_set_timeout > stream_set_write_buffer > stream_register_wrapper > stream_register_filter > > -Pollita > > > > > -- > PHP Documentation Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
