[PG-nuke-devel] Re: Current status... (fwd)

[Fabio A M. <ma...@al...>]

--------------------
Looking for a better .sig. Suggestions are being accepted.

---------- Forwarded message ----------
Date: Thu, 22 May 2003 09:43:53 +0200
From: rv...@dd...
To: Fabio A Mazzarino <ma...@al...>
Subject: Re: Current status...

Fabio,

here you find the a diff.

You can patch it agains the origional PHP-Nuke source using:

     patch -Np1 < PHP-nuke-6.5-pg.diff

It includes the rewriter and my nuke-pg.sql.

Ries


Citeren Fabio A Mazzarino <ma...@al...>:

>
>  (comments below...)
>
>  sorry if I'm answering too short, I'm in a flew. :o'P
>
> --------------------
> Looking for a better .sig. Suggestions are being accepted.
>
> On Wed, 21 May 2003 rv...@dd... wrote:
>
> !Citeren Fabio A Mazzarino <ma...@al...>:
> !
> !Hey Fabio,
> !
> !See comments between below.
> !
> !Here is my site's IP again with my new code, I didn't test all modules but
> I
> !didn't fine any anomalys so far, Currently I do a debug level 3 on
> postgreSQL
> !to see what and where it goes wrong: http://213.73.163.64:8080
>
>  I'll take look, as soon as my headache stops.
>
> !
> !I see I'm a developer now... would you like me to add my code so you can
> se
> !what I'm doing and how it works???
>
>  send me a tarball, I'll proudly set it up to you, and also take a look at
> you wonderful ideas ;o')
>
> !
> !regards,
> !Ries van Twisk
> !
> !
> !>
> !>  let's see... (hmmm.. interesting... :o)
> !>
> !> --------------------
> !> Looking for a better .sig. Suggestions are being accepted.
> !>
> !> On Tue, 20 May 2003 rv...@dd... wrote:
> !>
> !> !Fabio,
> !> !
> !> !
> !> !one question about case sensitivity, do your run windows on your
> !> !apache/php machine or do you have a all *nix situation?? I believe, if
> I
> !> !rememeber correctly that PHP4 is NOT case sensitive on a windows
> !> !platform. I think that postgreSQL on windows runs onder cygwin so the
> !> !behafure is the same omn *nix or windows. For your information my test
> !> !machine is a P233/3x4Gb HD/128MB ram/Debian Woody/PHP4/Apache
> !> !1.3.x/PostgreSQL 7.2.x
> !>
> !>  Now I remember this feature, I solved this in a very clever way :o)
> !
> !The 'fields_equiv.php' file is indeed a clever trick to work around the
> !case sensitivity problem, I never thought of that and I never thought
> !that was possible in PHP. I can make my script so that it spit's out all
> !SQL querys with a mixedcase result so while running it on a test server
> !it can detect the situation and allows to analyze if we are going into
> !the right direction and didn't miss a query. When I have some time I'll
> !put this in the code to, and again doing some code clean up..... :-)
> !
> !>  Note that FB and its followers don't use quotes when using arrays. I
> mean
> !> that these two statements are different:
> !>
> !>  $this_array[Item];
> !>  $this_array['Item'];
> !Corect...
> !
> !>  In most cases it returns the same item from the array, but there's a
> !> special case when it returns different results.
> !>
> !>  define('Item', 'item');
> !>
> !>  $this_array[Item];
> !>  $this_array['Item'];
> !>
> !>  Now we have what we want. ;o)
> !:-D
> !
> !>  In a first though, I have imagined that if FB discovers it he could
> make
> !> things harder, but as long as we have a set of scripts/regex to update
> new
> !> versions we can solve this very easy.
> !
> !Are you saying here that FB make it hard for us to do a port????? Or don't
> I
> !understand this correctly???
>
>  I expect everything from him, after knowing his ideas about free software
> and free development...
>
> !
> !>
> !> !
> !> !>  The main problem with rewriting SQL on the fly is that it might
> bring
> !> !> performance problems. I don't know if you agree with my aproach (do a
> !> !> branch instead plugin or something like).
> !> !>
> !> !I totally agree with your aproach but there are some things:
> !> !
> !> !1) It's differcult for your parser to do the rewriting because some
> !> !fields in the PHP4 code is calculated and so in PHP4 code it really
> does
> !> !not look like a query at all but with some clever scripts we may
> !> !overcome this. Still my rewriter may help you with it.
> !>
> !>  Actually I plan to analize exclusively whole parts of the code, I mean,
> !> ignore the dynamic part of the queries.
> !Okey.. and the rest by hand?? I didn't searched thrue the code so I don't
> know
> !the percentage that can by automated or not.. But rewriting PHP code with
> a
> !script just seems dangerous te me...but on the other hand I'm not a realy
> !script/perl/regex wizard to judge....
>
>  That's why I think that your method is better then mine. Although I have
> my reasons, your approach is much more generic.
>
> !
> !> !
> !> !2) I agree that it does need extra processor time and the current setup
> !> relays
> !> !heavenly on the backend but in the code we can cache somethings to
> speed
> !> the
> !> !rewriter up a lot. Most of the processor time will be in postgresql
> anyway
> !> and
> !> !I think that PHP4 is verly fast and computers aren't that expensive
> !> anymore..
> !>
> !>  I think that PHP-Nuke is a unexpensive option, and that's why it uses
> !> MySQL (lower CPU consumption). I'm trying to port it to PostgreSQL
> because
> !> it is a database highly accepted between corporations due to it
> !> strongness, and due to padronization (that's what corporations want)
> !I think it postgresql is cheap to...so is hardware... But I think he
> php_nuke
> !developers are just MySQL users and love the way MySQL just is so forgiven
> in
> !many ways and is easy to install and administer and ofcourse it's a
> historical
> !thing.
>
>  I know this, but we need corporate support so we can grow as popular
> branch/fork.
>
> !
> !>
> !> But we can work on both cases and test wich is better. Or even a
> !> friendly
> !> fork ;o) (I don't like the second option, but it's better if
> !>it's friendly
> !> :o)
> !Sure... Maby WE could make the effort the make the
> !'engine' fast and do a 'native' port to postgresql to speed things up
> !AND provide the rewriters scripts the 'support' 3th party blocks/modules
> !etc. etc. etc. So a not so good developer does not have to bother with
> !diving into code but just want's to have it's site running. We MUST make
> !sure that there isn't a good reason anymore NOT to choose for postgreSQL
> !and we can do this to also support 3th party modules. I don't want
> !people moving to mysql because 3th party module/block X does not work.
>
>  Perfect!
>
>  I like to listen to other opinions, altough I'll need to throw some code
> away. But a good idea is a good idea and it deserves the credit.
>
>  I was contacted today by another voluteer, I'll setup a mailing list
> (pg-nuke-devel) so we can chat and let others know what we are talking
> about, and what we are deciding.
>
>  I'll wait your tarball. ;o)
>
>  mazza.
>
>