Next phase in program
I started the next phase in the program to more or less replace the front page and, potentially, the PHP code: processing the request. It requires evaluation of the URL – or better: the part after the servername, and after that, the proper action should be taken depending on this evaluation. The assumption is that the home page – which can be a blog, by the way, is just the service, like “www.grootersnet.nl” – with, or without a trailing slash. “commands” are passed in a form as ?(action), as deplaying an index: “www.grootersnet.nl?index“, or “www.grootersnet.nl?i=-1” – or: give me the previous index page. I haven’t decided yet for the exact syntax. It could be just the first letter; i for index, p for page and r for recent, and on what other parameters.
Time will tell.
The basic framework is now done – it’s now a matter of parsing the command and do what’s needed. I think the easies part now is creating routines to retrieve the requested data from data storage, depending on the data type: Create an index page, or get the most recent post, or a given page -by number, to statrt with (I could think of retrieving a page by its date or title. A small portion has already been foreseen, so it wouldn’t be much trouble. Once these routines are created (and tested), processing of the data is fairly straightforward.
24-Feb-2008
No real issues – only an additional web
All seems well, on all systems. There are a few minor tweaks to take care of, but these are of class “somewhat annoying” and I can live well with them: it looks like the spam-list isn’t updated (I got a few messages slip through the mazes of PMAS that were discarded by SMTP, show up in the operator log but are missing in the list…)
The progress on the webpage program is more important at the moment.
The big thing, simply required to get on with the program, is running it as the main “page” – without reference to it’s actual location. No problem to map it, I thought, so I created a new service in WASD, to be usable from the local network only, and located on a separate port, so it wouldn’t interfere with all the other webs. I will run the program directly from the location that the building procedure will locate it on, but give it another name using a logical:
$ DEFINE/SYSTEM TSTEXE $1$DISK:[USER.DEV.EXE]
and map it all in HTTPD$MAP.CONF
map / /txtexe/wg_webpagedev map=once
exec /tstexe/* /tstexe/*
path /* /*testexe/*
like I have setup my mainpage (that uses “/cgi-bin/” under the hood)
It didn’t work: mapping was allright but once the ‘script’ was to be accessed, /tstexe/ was mentioned to be a bad name.
Finally, I took a look at the directory the home-exe runs under: cgi_bin. This proved to be a searchlist, to start with, but, like the blogs, both links are actully concealed devices!
After I defined TSTEXE as concealed device (there is no need (yet) for a searchlist) :
$ DEFINE/SYSTEM TSTEXE $1$DISK:[USER.DEV.EXE.]/TRANS=(CONCEALED)
and now it worked. I didn’t get the expected results (actually, I got the nasty “Not a valid CGI-response” error due to program errors not yet handled) but that was solved by creating and modifying the configuration file.
Expanding the code
The code has been expanded to show what’s read from the system (the symbols set up by tyhe webserver) and from the configuration, but just limited to the basic data. I added some more things to be displayed and it turned out that it wasn’t doing what it should: some data wasn’t accessed in the right place, or not at all. Some addition was made to the configuration and therefore the code, to get all data in place.
Once that proved to be right, the next phase is to load the report definitions, using the printLibrary routines (made years ago on VAX, and only recently ported to Alpha). Originally, the OpenReport function would do this, and prepare output as well. However, this is not feasable in this situation where output isn’t to be opened at all – yet – so I had to add another routine in the (FORTRAN) code of the print library routines: InitReport – actually the same as OpenReport but without accessing output. Another advantage is that here I can now specify the library – where OpenReport relies on logical PRINTLIB (this hasn’t changed). This new routine is now called to initialize the pages. So far, it looks good, in both html-output as plain ASCII.
It also meant I had to review the environment code I created before to access these routines. Some required attributes were still missing, and arguments that change, needed to be specified to be VAR.
Now I can start getting data, but first I should determine WAHT to get if no arguments are specified. It means another addition to the configuration file and structures (and code). It’s just more of the same and no problem at all.
21-feb-2008
Coding
Bit by bit, the program for dynamic content continues. Small steps at a time since it’s just a few hours on some days, and none on others.
It required slight updates for already present library routines, though the vast majority just does what it should do. I only found a slight mistake in one of the routines interfacing to Mark Daniel’s CGILIB, and that caused a problem getting data from the server. This has now been solved, and at this moment, the retrieval of required server symbols works, as well as the basis configuration for both home and blog-definitions.
Next will be the initialisation of all reports. The basics are alrteady in use in the current homepage, actually a derivate of the testprogram for all reporting routines, where the texts are hardcoded. But all of the html code is saved as a report in the text library. There is no HTML-generating code in this program!
And that’s what I want it to be like.
Some thoughts are still maturing – not at all fit for implematation, but to give an idea:
Not necessaraly in that order. Give it time, it may, or may not, appear in a future release.
(I noticed I have to adjust the specification of LIST items here – but that can only be done on the server itself, I have no access to the files via the web – for obvious reasons of security. In the mean time, I did some <font> specification, to make at least the text more readable)
Keeping yourself employed
If you would like to stay on a project – forever – you may like this esay. Meant for Java, it applies to ANY language. I’ve had to handle code that adhered to at least some of the methods mentioned 🙁
SQLite and GNV
wg_webpage
The major work at the moment is getting a program running that takes input from a file and dunps it into a webpage. The basics behind it: the forementioned routines, did work already and the testprogram has been modified to show at least a hardcoded content. But coding the whole lot from there proved more troublesome than anticipated so I deciced to redo the program from scratch – but use what’s already working.
One thing I encounterd is a serverless SQL engine, used in the anti-spam gateway to store statistics: SQLite. I downloaded the sources and was trying to get it to compile, to begin with, but that didn’t work. next I tried using the GNV package – I still had 1.6 on the box. the configure script ran up to checking the header files and stalled there. In a brain flash I downloaded and installed the latest (2.1) version and ran into some problems: The directory was accessable only for displaying the contents. CD to it fails, as well as running a script. Put a message on ITRC and got the answer to get to the directory – but running the script fails in a number of places and doesn’t get as far as running under GNV 1.6. It appears the scripts needs to be updated in one place, and some adaptions are to be made to circumvent some other problems. There may be some bits missing, so I’ll have to get these as well.
One thing I noted: the modules need to be built /NOANSI, and /FLOAT=IEEE. But that’s a minor issue. With this knowledge, it may be possible to circumvent GNV.