Tool's *Update Available Info* / Version Spectrum Analysis

Posted: Thu Oct 28, 2004 2:13 am

Cheers,

Thought I post this in this section...

In the next presented scenario, PHP Developer wishes to accomplish following targets:

(1) To inform customers/parties on Tool's available "Update"/"New Release"
(2) To track down the version spectrum of the actively utilized Tool

I wonder what he/she might be getting out that? More or less? Oh, yes I know - less is more. But, that's out of the question.

-->

(1) to inform customers/parties on Tool's available "Update"/"New Release"

Realizing one of the *easiest, fastest and least resource consuming* methods/approaches for delivering *update available information* for customers/3rd-parties; "Dynamically Generated PNG".

In this approach/scenario the PNG will be generated DYNAMICALLY at the mother Site's Staff/Admin(s), once the released update is available - optionally the same image placeholder may be equipped (at any stage) with different closely related information, such as an estimate for the availability - on next planned update. It should be noted that, this "dynamically generated PNG" is not supposed to be generated by the people accessing the PNG - instead, they will simply "upload" it into their Admin Panels Views" (in case of PHP-Nuke).

So, as soon as the Tool's Staff thinks it's time to let the Good News loose on the available update, the PNG will be then UPDATED by the Staff, by executing a GDLIB dedicated PHP script - reserved for these purposes only. The GDLIB related PHP Driver (script) will then at the PNG update occasion access the *specific data* from the MySQL DB, into which no one else has an access, but the trusted Authors, to perform the dynamically generated PNG update operation. This result will be then set "downloadable" by the "customers/associated parties" dealing with their Admin Panels.

Hey, wait a minute - a dynamically generated PNG - but, there's not supposed to be any PNG after it has been tmp-generated? A: Oh, yes there is (in this case at least) - as it depends totally on whether you leave or not a "copy" of the dynamically generated PNG on your server, i.e. fully script architecture dependent.

OK, so that's all? Some more yet to come - let's continue...

So, extending this slightly, a parallel approach to this (being available for all customers/parties) would be to instantiate another instance for *subscribed users* on available critical/classifed updates/news/etc - this image containing the necessary *classified update info* would be then set accessible on *.htaccess - allow ip basis* for anticipated/justified sources attempting to retrieve the info PNG #2.

(2) To track down the version spectrum of the actively utilized Tool

I suppose that many serious Dev's may/would consider it worth an implementation to have it "all figured out" about the Version Coverage Spectrum of a Tool.

Q : How to accomplish it - at least with some reliability on it? Making a phone Call?
A : Dynamically Generated PNG - the very same that was figuratively being used in the (1) section.

So, just by assigning each new Tool Release with a new *UNIQUE PNG IDENTIFIER*, the calls from diffrent Tools version will have unique identifiers along with them. - hence, each time the PNG is accessed from the Mother Site, there will be a trace left into the Server Logs - by processing the Logs (which is not a difficult/time consuming routine), the Mother Site Administration will then get a chance to have glance at the Statistical viewpoint upon the Version Spectrum of a Tool - i.e. a Stas View on which versions of the Tool are contemporarily being actively used (and in which geographical regions, i.e. server IP decoding).

So what's the use? I suppose, that depending on ones goals'n'targets as a PHP Dev, this kind of approach might be well be turned out into something good - whether from the business/strategical perspective or just from the security perspective..., (hush-hush) Smile

The only BANDWIDTH/RESOURCE consumption that would be generated per this applied approach, would derive from people's "PNG downloads" (local server Admin Panel uploads) into their Admin Panels (each time they deal with the dedicated Admin Panel section). Let's suppose, that the PNG is 88x16 containing the *update available information* - it becomes immediately clear that this may not cause any *annoyances* from resource management point of view.

It might be well applicable to try out at some stage - whadda ya think?

BR,

-beetraham

Site Admin/Owner Joined: Aug 27, 2002 Posts: 17088

Have you tried this yourself to see how it works?

Posted: Thu Oct 28, 2004 10:50 am

Raven wrote:

Have you tried this yourself to see how it works?

Actually not - this was just a thought but I think it could be interesting to put up with a virtual "DUT + TB" env, as it is not a heavy task to accomplish.

DUT/TB - Light-Features:

Code:

-DUT [Device Under Test]


       - virtual application, but a real with Admin Panel


-TB  [testbenc]


       - a "cron"/"pseudo-cron" job, CSH/SH, that will parse Apache web server log files;


   - parsing # of hits in a timeframe (per IP / timeframe / version )


   - generating MySQL Dump INSERTS for MySQL uploading purposes


            => parsing further the extracted version spectrum related info graphs (GBLIB, PHP)


            => processing the the extracted stats into a "searchable" DTML Table

As accomplished, making it all as insertable/portable as possible for any PHP-Nuke Environment related Tool/CMS/etc. (though it would always require some custom work)

Virtual Application, version spectrum manager, Contents (a raw test scheme):

Quote:

|
+---html
¦ ¦
¦ +---admin
¦ ¦ +---case
¦ ¦ ¦ case.vsm.php
¦ ¦ ¦
¦ ¦ +---language
¦ ¦ ¦ +---vsm_admin
¦ ¦ ¦ index.html
¦ ¦ ¦ lang-english.php
¦ ¦ ¦
¦ ¦ +---links
¦ ¦ ¦ links.vsm.php
¦ ¦ ¦
¦ ¦ +---modules
¦ ¦ vsm.php
¦ ¦
¦ +---images
¦ ¦ +---vsm
¦ ¦ ¦ vsm_version1.png
¦ ¦ ¦ vsm_version2.png
¦ ¦ ¦ vsm_version3.png
¦ ¦ ¦ vsm_subscriber.png
...

I'll provide an update on this as soon as I have got some results to share/judge, if found as a working/applicable solution.

Thanks,

-beetraham