Re: [Rlib-devel] Example report XML files

[Bob D. <bd...@si...>]

> 
> I haven't had much time as things have be very busy at work however I
> am now making pretty good progress.  The functionality is almost up
> to the PHP interface however I've run into what I consider warts on
> the interface.  With PHP you pretty much expect that the program
> activate, process, and then die with every request so having a lot of
> globals is kinda normal although that might change with PHP 5.
> With python using globals is considered poor/lazy/hack programming.
> The first issue, which can't be worked around if I'm going to get
> the m.variable idiom to work, is that the "environment" needs
> to track/store/pass a user variable to all of it's functions.
> I need this to be able to do reference counting on python objects
> as well as freeing temporary memory.  

I took a look at your pass rlib struct to the environment patch.  I
don't really understand why we need to use the rlib struct.  Can't it
just be a gpointer to something the environment mallocs then frees?

Other things like PHP, C can just ignore it.

I worry that if the environment (3rd party languages: PHP, Python, PERL,
ect) have more direct acesss to that memory the odds of it being
clobbered due to a programming mistake are greater.  And debugging those
things are less then fun ;)


> The second is with the
> adding of the array datasource.  The add_datasource_array call just
> says I'm going to give you one, the add_query_as passes the name
> of the array as a string, which is then looked up in the global
> name space.  My thought here would be to deviate from the other
> implementations and have the add_datasource_array take a reference
> to the array and then ignore the query string, this allows me to use
> normal variable scope resolution so the array doesn't have to be global.
> The problem of course is that deviations cause major confusion when
> people are trying to port code (humm, now that I think about it I'll
> have to look at what the C implementation does, I only looked at the
> PHP one as that seems to be the predominant usage target).

This is a tough problem.

rlib_add_query_pointer_as already exists (Although I don't think its
binded yet)

It's main difference is it doesn't strdup the sql pointer.  Although the
sql pointer should not be a char * but a gpointer now that I think about
it....

Maybe Both PHP and Python should support both ways or perhaps only
"rlib_add_query_pointer_as".  I don't have a problem with the latter as
it's more correct.  The reason it's global now is because I didn't know
how to do it any better in PHP at the time due to lack of internal PHP
documentation.