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

[CheolMin L. <cm...@us...>]

LTNS :)

On Sun, Dec 23, 2001 at 02:00:54AM -0600, Brian Foddy wrote:
> 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?  

good idea. BTW, is it working well for pipe or socket?
I checked in your recently updated code and found that 
php_file_le_fopen() was used to get the resource.
I'm wondering that php_file_le_fopen() works for pipe or socket 
even if not using php_file_le_popen() or php_file_le_socket().

I'm not an expert in Zend and PHP. So just curious.

> 
> 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 like it.

> 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
> 
> 
> 

-- 
CheolMin Lee <cmlee @ users.sourceforge.net>  
             <cmlee @ kt.co.kr> <cmlee @ bigfoot.com>