Re: [Php-tuxedo-development] CVS updates (resend)

[Brian F. <bf...@mn...>]

CheolMin,
Haven't heard from you in awhile, how goes Php-Tuxedo?

I've been making some updates to get it running on
Php 4.1 and some other long overdue changes, and
I'd like to propose a small change to your
tux_ffprint function...

Rather than have it open and close the file,
how about passing it a already open PHP open
file reference, and have it use it.  I've got
most of the designs ready to do this, but it
would probably involve changing the arg types,
hence would break anything you've written using your
arguments.

Thoughts?  

I've given some thought to try and overload
the argument type so it can go either way, but
I'd rather just keep it clean and use PHP files.
The advantage should be it would work for sockets
and other file types.  I don't know if that would
ever be used, but at least its available.

Also, I was looking at the "data" argument you added
to tux_tpinit...  Is it ever possible "data" could be
a binary value, hence the strlen and strcpy could fail?
I'm proposing we use memcpy and the internal PHP API
data length argument for binary safeness.

I can't believe its been 4 months since your changes,
I've been so busy I haven't had time to keep the project
moving.  But I got a few emails recently of others
using the project and I knew I had to get your changes,
4.1 support, and other fixes in an official release.

Thanks for you help so far...
Brian


On Tue, 21 Aug 2001 18:58:11 +0900, CheolMin Lee wrote:

>Hi, PHP-TUXEDOers.
>
>I committed some updates for PHP-Tuxedo 0.3.5.
>
>  1. tux_tpinit has one more but optional argument
>  2. tux_tuxreadenv was fixed
>  3. tux_fget was implemented
>  4. tux_ffprint was implemented
>
>Let me explain the above changes.
>
>[1]
>Brian's original version of tux_tpinit has 4 arguments: user name, 
>client name, application password and flags.
>These are essential. However, if someone want to take more powerful
>security level such as USER_AUTH and ACL in their Tuxedo application,
>TPINIT buffer must have the user-level authentication data which is
>usually user password.
>So I added the optional argument, data, into the tux_tpinit.
>You can use the funtion in the php source like this:
>
>  tux_tpinit($username, $clientname, $app_passwd, $flag, $user_passwd);
>
>
>[2]
>tux_tuxreadenv() is my contribution to this project. It works good but
>sometimes not good. :)
>In the same PHP scope(that is, it the same PHP file) if tux_tuxreadenv()
>occurs two or more times with mutually different tuxedo environemnt 
>especially FML-related, FieldName->FieldID mapping table happend to be
>dirty. So the following functions such as tux_array2fml() may work abnormally.
>
>I fixed this problem with placing Fnmid_unload() before tuxreadenv().
>
>
>[3]
>tux_fget() is added.
>
>Synopsis
>  mixed tux_fget (resource FML_buffer, int field_id [, int occ])
>
>  Returns the corresponding the value of the field occurrence, or FALSE
>  if some error occurs
>
>     FML_buffer is FML buffer resource reference
>     field_id is FML Field identifier
>     occ is occurrence number of the field
>
>I temporarily implemented this function takes not field name but field id 
>to indicate a field because of preserving consistency with tux_fadd, tux_flen, 
>etc. But, I think it is more convenient to take field name as the argument
>when using in the real world. For example:
>
>  tux_fget($fmlbuf, tux_fldid("A_FIELD", TUX_FML));
>
>  vs.
>
>  tux_fget($fmlbuf, "A_FIELD"); /* FML or FML32 depends on $fmlbuf */
>
>Which one do you like?
>
>
>[4]
>tux_ffprint() is added.
>
>Synopsis
>  int tux_ffprint (resource FML_buffer, string file_path [, string mode])
>
>  Returns the return value of Ffprint(32).
>
>     FML_buffer is FML buffer resource reference
>     file_path is output file path name
>     mode is file open mode("a", "w", etc)
>    
>This is another implementation of Brian's tux_ffprintf().
>Brian's implementation is to print FML buffer into the pre-defined file
>which is "/tmp/php_tux.out". Will it be a potential security hole?
>I have no idea.
>Anyway tux_ffprint() takes the file path from the PHP users, and I think
>this would be a replacement of tux_ffprintf().
>How about taking tux_ffprint() instead of tux_ffprintf() in the next version?
>
>-- 
>CheolMin Lee <cmlee @ kt.co.kr> 
>             <cmlee @ users.sf.net> <cmlee @ bigfoot.com>
>
>_______________________________________________
>Php-tuxedo-development mailing list
>Php...@li...
>http://lists.sourceforge.net/lists/listinfo/php-tuxedo-development