[PHP-DOC] Re: install part thoughts
Hi, - Original Message - From: "Gabor Hojtsy" <[EMAIL PROTECTED]> To: "Papp, Gyozo" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Wednesday, April 17, 2002 9:13 PM Subject: Re: install part thoughts | > This can be aa very good starting point. Each function reference | > should contain two additional files: | | I guess you intended to write this the other way round ;) Yes, just for the sake of clarity (repeat'em): config.xml -- installation (compile time) instruction ini.xml-- everything related to php.ini (maybe?) | > Yes, security is much more. I'm afraid that users tend to disregard it | > by putting it into an appendix (to the end of the manual). | > BTW, I have an other problem with its current location. I think a newbie | > must read a lot ahead -- at least to the language section --, and return | > back to these security manners to really understand what it's about. | > | > Can security.xml be put into "features" directory or distribute its | > content in other .xml's? (just not an appendix :) | | I can't think of any right method to distribute security.xml content | into extension parts. This is a topic that needs to be included in | whole... I had the same thought about dispersing security infos elsewhere, but I'm really afraid that users may disregard it. (have a look what's in the appendixes now?)
[PHP-DOC] Re: install part thoughts
Hi, | to have a solution for that ugly file structure introduced in install | files, and find final places for install files. Yes we really need a solution which will stand the test of time. It will cause me a big headache to keep up with the updates in install chapter if the other languages (including "hu") cannot/ don't follow the recent english file structure. There were a little discussion how the install.xml can be split and distributed reasonably between existing dirs and with creating new ones. But no decision yet. Some months ago it could be acceptable that translators would need to do their job twice if they jumped to the new english install files immediately - not waiting for a fully deliberated configuration. Now time goes by, new stable Apache has been released, PHP 4.2.0 comes soon. More and more people will be eager to read the most recent installation steps to make work together their favourite dev tools. IMO, translators should translate these new instructions... | First of all 90% of config.xml and install.configure.*.xml files | can be distributed into extension documentation files. The question | is who has the time to do this, and how to do this. | For now, we have mysql/reference.xml [and maybe some others] | with the ini info moved into the extension reference. IMHO it would | be the best to have a configure.xml and an ini.xml file in every | reference dir with the corresponding configure and ini stuff. | These files can of course contain the same [or similar] structure | used in mysql/reference.xml This can be aa very good starting point. Each function reference should contain two additional files: ini.xml-- installation (compile time) instruction config.xml -- everything related to php.ini (maybe?) | So then intro.xml install.*.xml and security.xml will be left | in chapters/. We'll we previously agreed (as I remember ;), | that chapters is a really odd name for this. And we also agreed | on a new directory named install for general, and server related | installation information. | | So intro.xml and security.xml is left in chapters... IMHO security | is a kind of appendix, though it is much more important than to be | an appendix... Intro needs some more info, the integration of Yes, security is much more. I'm afraid that users tend to disregard it by putting it into an appendix (to the end of the manual). BTW, I have an other problem with its current location. I think a newbie must read a lot ahead -- at least to the language section --, and return back to these security manners to really understand what it's about. Can security.xml be put into "features" directory or distribute its content in other .xml's? (just not an appendix :)
[PHP-DOC] extension categories
Hi, here's my contribution to one of TODO items: categorizing the sprawling "Function Reference" items. The guidelines I followed were: - categorize in two level depth: * the first level is numbered one (from 1 to 11 now) it should be a real link in TOC * the second one is the "labels" level. Labels (in parenthesis) divide huge lists into smaller parts and help focusing to the item in request by showing some appropiate keywords. - use a manageable number of groups (not too many and not too few) It may be a good start somewhere around 10. - give the most descriptive and the shortest name to each group as possible (as i can). It doesn't mean I score this goal. - having a "basic" category where the very basic extensions are grouped together which are mentioned or discussed in the "Language Reference" part and possibly in the "Features" part. I assume that it'd be worth knowing about these extensions or functions. This knowlegde, on the one hand, might be indispensable, and on the other hand may yield very efficient and well structured and featured PHP programs without respect of its special task. I've put some web related function reference in the "Basic" category, because I think the main target of using PHP is still web programing. dir.xml and filesystem.xml is placed under "FileSystem & Process Control", but it can be a good thing to put these ones into the "basic" category and to rename "FileSystem & Process Control" to "Process Control" simply. So, discuss it! 1) Basic PHP (PHP++ :) -- (variable & type related extensions) array.xml Array Functions classobj.xml Class/Object Functions ctype.xml Character type functions funchand.xml Function Handling functions string.xmlString functions pcre.xml Regular Expression Functions (Perl-Compatible) regex.xml Regular Expression Functions (POSIX Extended) var.xml Variable Functions (affecting PHP's behaviour) overload.xml Object property and method call overloading errorfunc.xml Error Handling and Logging Functions http.xml HTTP functions info.xml PHP Options&Information outcontrol.xml Output Control Functions (session) mohawk.xml Mohawk Software session handler functions muscat.xml muscat functions session.xmlSession handling functions (???) misc.xml Miscellaneous functions url.xmlURL Functions 2) Database Support --- (abstraction layers) dba.xmlDatabase (dbm-style) abstraction layer functions dbx.xmldbx functions uodbc.xml Unified ODBC functions (vendor specific) dbase.xml dBase functions dbm.xmlDBM Functions dbplus.xml DB++ Functions filepro.xmlfilePro functions fbsql.xml FrontBase Functions ifx.xmlInformix functions ibase.xml InterBase functions ingres-ii.xml Ingres II functions mssql.xml Microsoft SQL Server functions mysql.xml MySQL Functions msql.xml mSQL functions oci8.xml Oracle 8 functions oracle.xml Oracle functions ovrimos.xmlOvrimos SQL functions pgsql.xml PostgreSQL functions sesam.xml SESAM database functions sybase.xml Sybase functions 3) XML -- domxml.xml DOM XML functions qtdom.xml qtdom functions wddx.xml WDDX Functions xml.xmlXML parser functions xmlrpc.xml XMLRPC functions ??? xslt.xml XSLT functions 4) Credit Card (e-commerce may be too wide) --- ccvs.xml CCVS API Functions cybercash.xml Cybercash payment functions cybermut.xml Crédit Mutuel CyberMUT functions pfpro.xml Verisign Payflow Pro functions 5) Math & Cryptography -- (math) bcmath.xml BCMath Arbitrary Precision Mathematics Functions gmp.xmlGMP functions math.xml Mathematical Functions (cryptography) crack.xml Crack functions mcrypt.xml Mcrypt Encryption Functions mhash.xml Mhash Functions 6) Internationalization & Character Encoding Support --- fribidi.xmlFriBiDi functions gettext.xmlGettext recode.xml GNU Recode functions iconv.xml iconv functions mbstring.xml Multi-Byte String Functions 7) FileSystem & Process Control --- (filesystem) dir.xmlDirectory functions filesystem.xml Filesystem functions (process) posix.xml POSIX functions pcntl.xml Process Control Functions exec.xml Program Execution functions sem.xmlSemaphore and Shared Memory Functions shmop.sml Shared Memory Functions 8) Accessing Other Services --- curl.xml CURL, Client URL Library F
[PHP-DOC] NEW dbx.xml
Hi, everyone interested in dbx.xml! In the last few days I've spent a little time on reformulate the dbx.xml documentation. I consulted with Marc Boeren <[EMAIL PROTECTED]> the author of this extension, and he agreed with my changes. If any translator has problems with the new version of dbx.xml which will be commited soon, please feel free to notify me! I do my best to help you out. PS: pay attention to the next upcoming reversion of dbx.xml! Papp Gyozo - [EMAIL PROTECTED]
Re: [PHP-DOC] fopen_with_path - remove it?
Then it remains. - Original Message - From: "Gabor Hojtsy" <[EMAIL PROTECTED]> To: "Papp Gyozo" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Thursday, February 14, 2002 6:20 PM Subject: Re: [PHP-DOC] fopen_with_path - remove it? | > in c o n f i g . x m l (on line 453) there is a reference to | > fopen_with_path() function. | > | > " and fopen_with_path functions look for | > | > Does it exist or not? I doubt it, because the third parameter of | > fopen() does the same thing as I presume after its name. | > | > So, may I remove it? | | I checked this in the PHP source, and it seems ot be a PHPAPI | function, and not a function for the userspace... | | Goba | |
[PHP-DOC] fopen_with_path - remove it?
in c o n f i g . x m l (on line 453) there is a reference to fopen_with_path() function. " and fopen_with_path functions look for Does it exist or not? I doubt it, because the third parameter of fopen() does the same thing as I presume after its name. So, may I remove it? Papp Gyozo - [EMAIL PROTECTED]
[PHP-DOC] strings.xml
Hello, I wanted to add references to preg_match and preg_replace functions beside ereg and ereg_replace in the english strings.xml, but I've "insufficient karma". Please someone, commit it - I attached the zip file (beware the revision number, obviously i cannot tell it) Papp Gyozo - [EMAIL PROTECTED] strings.zip Description: Zip compressed data
[PHP-DOC] [PROPOSAL] database security issue
Hello, while surfing on the net I've found a few articles about web based appliction security and a dedicated site: Open Web Application Security Project where I read this article: http://www.owasp.org/projects/asac/iv-sqlinjection.shtml I'd love to know your position on writing a short section about "SQL injection and others" in security.xml, something similar has already done for filesystem security. It aims to be an introduction into the very basics of PHP related database security and vulnerability, because: " the strongest and most significant feature of PHP is " its support for a wide range of databases. Writing " a database-enabled web page is incredibly simple. [from the manual :)] IMHO, it's indeed incredible simple, but users must be aware of this attacking technique, too. What do you think? I have further examples and some avoiding techniques, and hopefully you may also share your valuable knowledge about this topic. Papp Gyozo - [EMAIL PROTECTED]
Re: [PHP-DOC] cvs: phpdoc /en/functions array.xml
From: "Egon Schmid" <[EMAIL PROTECTED]> Subject: Re: [PHP-DOC] cvs: phpdoc /en/functions array.xml | From: "Gyozo Papp" <[EMAIL PROTECTED]> | | > pgerzson Fri Jan 4 09:34:02 2002 EDT | > | > Modified files: | > /phpdoc/en/functions array.xml | > Log: | > correct "See also" cross references and exampe outputs for | several functions | > and array_unique note on preserving keys | | Oh, I haven´t understood what you said about the comma. The rules in | English are the following: Did I say anything about commas? ;) You're right I removed several commas without notice. | | See also func1 and func2. | See also func1, func2, and func3. | See also func1, func2, func3, and func4. Please forgive my ignorance, I haven't known this rule in English yet. (about comma usage in enumaration). I have only one excuse that in Hungarian there should not be used comma and any conjuction such as 'and' together. | | I have looked at the diff and I have seen another minor | incorrectness. The space between "and" and "" have | sometimes removed. The rendering would look like this (see the last | change line): | | ... andrsort(). | OK, I'll correct it and commit again.
[PHP-DOC] about array.xml 2.
1)
OK, pos() and sizeof() remains.
Maybe have a link to appendix G "List of Function Aliases"?
I've just realized that the doc says there are two kind of alias.
(decrepated ones and very basic ones as earlier mentioned)
It may worth mentioning this difference with a link, or not?
If so, how does this link look?
alias
2)
I'm currently working on the example outputs. I use the following
tagging:
foo example
The printout of the program above will be:
(by default, or the existing description after the examples, if provided)
is it correct? (I copied from the array_chunk or whatever entry
from the beginning of the array.xml)
3)
I looked into the source searching for array_unique. I found the same
implementation in 4.0.6 and 4.1.1 (I haven't got any earlier local
source). In my understanding this implementation of array_unique
does remove every duplicates after the first value, and now I can figue
out the meaning of "keeping the first key encountered for every value".
I think it is only a documentation issue. My suggestion is that the
manual should state:
" array_unique() sorts the array values (treated as strings?) at first,
" and then it keeps the first key encountered for every value. It does
" not mean that the key of the first related value from the unsorted
" array will be kept.
and hopefully everything would be much more clear.
Can anybody familiar with the source approve my proposition or fwd it
to phpdev list?
(here comes the snippet from ext/standard/array.c:)
PHP_FUNCTION(array_unique)
...
for (i = 0, p = target_hash->pListHead; p; i++, p = p->pListNext)
arTmp[i] = p;
arTmp[i] = NULL;
set_compare_func(SORT_STRING TSRMLS_CC);
qsort((void *) arTmp, i, sizeof(Bucket *), array_data_compare);
/* go through the sorted array and delete duplicates from the copy */
lastkept = arTmp;
for (cmpdata = arTmp + 1; *cmpdata; cmpdata++) {
if (array_data_compare(lastkept, cmpdata)) {
lastkept = cmpdata;
} else {
p = *cmpdata;
if (p->nKeyLength)
zend_hash_del(Z_ARRVAL_P(return_value), p->arKey, p->nKeyLength);
else
zend_hash_index_del(Z_ARRVAL_P(return_value), p->h);
}
}
...
ps: Not to waste any time I have committed all the changes above
(rev 1.148). Please make test im my stead because I haven't set
up my test environment yet.
Papp Gyozo
- [EMAIL PROTECTED]
