Re: [MinGW-dvlpr] Download page generated content

[Leif W <war...@us...>]

> "Earnie Boyd" <ea...@us...>; 2005-02-16@08:22 GMT-5
>
>> <quote who="Leif W">
>>
>> Q1) Is there a specific feature that would be desired, or is anything
>>     undesirable?
>
> Possibly choosing the download mirror from the website rather than
> spawning to SF?

Oh yeah, that's a good one, thanks!  IIRC, the mirrors list seems to
change a bit.  I don't know if it's just reordered, or if only a segment
of the entire list is ever shown.  I can either try to discover the list
manually, and keep a static copy somewhere, or just pull the list
dynamically.

>> Q3) Any objections to an object-oriented approach?
>
> No.  Store the object in the $_SESSION global variable.  If the object
> variable exists use it otherwise create a new object.  I tend to do
> something like
>
> <snippet>
> if (! isset ($_SESSION ['MYOBJ'])) {
>   $_SESSION ['MYOBJ'] = new MYCLASS;
> )
> $MYOBJ = &$_SESSION ['MYOBJ'];
> </snippet>

Oh, I hadn't even thought about sessions.  Is there a possibility that
things collide without sessions?  Does this only happen if php is a
shared module or something like FastCGI combines multiple calls to php 
to a single cgi instance?  I'll definitely read up on this.

>> I've been thinking of a page request level script, and cache the web
>> pages, and cache the data in an file for faster retrieval on
>> subsequent
>> calls.  I was thinking of an XML file format, hoping that subsequent
>
> I don't know that I would worry about cache methods beyond what the
> server
> already supplies.  IIRC, mcache is already used for PHP and Apache.

Oh, I didn't think the files would be stored in memory after the
request.  Also I thought the entire parsing routine would have to be
done again.
I guess my main idea for a cache file is incase the parsing breaks on
the download or project pages, at least the content on the MinGW site
will only be stale, and not broken as well.  Also, to save time on
subsequent parsing by removing all that extranneous HTML, and eliminate
the wait for server response.

>> Q6) XML or custom file format (string separated values: '\t', ':',
>>     etc.)?
>
> No opinion.

I'm not 100% sure myself if parsing an XML would be any faster than a
simpler config syntax, but the XML would possibly be more versatile.  It
would be easy for anyone else to get the info in the future if it is all
in one place in a format that won't break if it's extended.  This may be
a bell or a whistle, so it's a medium priority.

>> Q7) Should a logfile exist, when should it be used, and what content
>> and
>>     format?
>
> I can't think of a reason why we need it.  Maybe include one if a
> DEBUGIT
> variable is set.

I'll look into making at least a verbose/debug level.  I've not done
this before.  Is it usually achieved with a bunch of 'if' or 'switch'
statements?  I'd hate to clutter the code if there's a cleaner way.
Usually I litter the code with echos when developing and remove them, 
but that's a crappy strategy for maintenance.  :p

if ( $status == FALSE )
{
    switch $debug
    {
        case 3:
            // run without the @, tweak the php error levels, etc.
        case 2:
            echo "message<br>\n";
        case 1:
            log( "message" );
        default:
    }
}


Leif