How did this project come about?

After more than a decade of experience Ive decided its finally time to add a voice to my webpresence. Ive got all the blog accounts but theyre impossible to use, & Im not going to run my own server just so I can customise some css. I need absolute control over the layout & the management of the posts & I need to be able to place the blog on any ordinary (free) webserver of my choice. To implement the "look & feel" of a blog there are some issues concerning common code which have to be addressed, particularly with respect to maintenance.

Whats wrong with mainstream blogs?

The layout generally can only be customised in a limited number of ways. Plus youre locked in to their post management method, usually an editor window which permits at best a subset of HTML tags in the text. Most significantly the chrono ordering of posts is a nightmare. If you go back & correct an old post it may wind up with a new date, & sometimes to desquirrel something you have to repost it completely. If you want a standard "welcome" post on top you often have to keep it reposted as the most recent document. Finally, a web-based blog interface is like web-based eMail. Once you understand the internet you dont want the overhead & intransigence of the interactive connection.

What dont you need from blogging software?

Im not up for the community aspects & comments; I can leave that for another site. I also can do without search capability & the various types of automatic indexing, calendars, &c. Historically the blog helped replace usenet & other unnecessary bandwidth abuses simply by providing a place to publish other than ones eMail outbox. Perhaps Im actually creating a wiki, but Im still calling it a blog.

What are the options for engineering blogwrapper code for posts?

The primary consideration is that the standard code -- header, sidebar, footer, optional elements -- be separated from the document store so its maintained in only one place but changes are still reflected in all the posts. The web does this particularly poorly. Ideally the blog page would be coded in one piece & somehow passed an argument pointing to the post which would be rendered at a given point within the page; proponents of css claim this is what is effected via stylesheets. Alternatively each document could have a conventional markup which points to the common elements & theyre dynamically acquired when served. Legacy HTML does this via (I)FRAMEs or OBJECT but they are unevenly supported & impossible to implement. PHP/SSI (& to a lesser extent client side javascript) can be made to dynamically generate a page from components each time its served, but they require that these technologies be installed & operative. In short, its far easier to create a batch process which assembles complete blogpages from posts & common code, resulting in ordinary HTML which can be uploaded to the host. Although startlingly trivial via the C preprocessor, Ive opted for a Linux shellscript in the interests of crossplatform compatability.

So how does it work?

First of all, the code & documents are composed / maintained on the local machine via the preferred editor(s). Source posts are kept in an absolute de minimus form as ordinary ASCII text files. Although not a complete webpage, a post contains HTML markup beginning with a standard header which is a table containing the title & date. The rest is text in wrapped paragraphs & whatever further explicit HTML is desired. Second, complete webpages are generated by the "blog compiler" which assembles them by pre- & postpending the blog wrapper(s) around the individual posts. The gen script (below) issues one cat command for each member of the document store. If a change is made only to a single document, it can be regenned by itself. Alternatively, all documents in the system can be regenned when a change is made to the common code.

#!/bin/sh
#========

echo ooo
echo building blog posts ...
date +%G%b%d%a.%P%H:%M:%S
uname -srm

# gen_blog v2.005 for planitiapost
# creates index.html & gens all src/s*.htm
# run from the blog directory (eg via mc)

  genblogs() {
    [ -f src/s$1.htm ] && \
      { cat zdxhi01.htm \
            src/s$1.htm \
            zdxin01.htm \
            zdxlo01.htm
      } > i$1.html
  return 0
  }

  genviews() {
    [ -f src/sdv$1.htm ] && \
      { cat zViewhi.htm
        echo "mdc$1.jpg"
        cat zViewlo.htm
      } > idv$1.html
  return 0
  }

  cat zdxhi01.htm  \
      sdxindex.htm \
      zdxin01.htm  \
      zdxlo01.htm  > index.html

  for proj in src/sdc* src/sdp* src/sdx* ; do
    proj=${proj##*src/s} ; proj=${proj%%.htm*}
    echo ${proj} ; genblogs ${proj}
  done

  for proj in src/sdv* ; do
    proj=${proj##*src/sdv} ; proj=${proj%%.htm*}
    echo ${proj} ; genviews ${proj}
  done

exit 0

What are the considerations for the design of the blogpage?

A good webpage renders viably on a wide variety of browsers & platforms & avoids horizontal scrolling. At this writing I test my pages on Firefox, Netscape, Opera, Explorer, & Lynx (XP), & on Firefox, Opera, Lynx, & Links2 (Linux). I try to use the most trivial possible HTML including ordinary <table> tags for the sidebar. To this day I remain a dedicated 800x600 user & expect the page to expand or contract properly whatever the resolution, & to look good in text mode. Although it is good practice to avoid specifying explicit pixel widths for areas, images, & tables, this is not all that is needed to achieve universal scalability. Proper text wrapping seems to have been universally achieved in all contexts under (almost) all browsers, but images remain another issue.

What is width="100%" of the "available space"?

Consider an ordinary blog post with an inline image & perhaps an inline table. Elementary rendering would be in the entire screen width where "available space" is almost a redundant concept. But browsers are also supposed to support content "flowing" around items aligned at the screen edges, & content rendered inside a table cell. Here "available space" is narrower than the screen width & in the former case is actually subject to change. For historical reasons specification of a 100% width on items which accept it (images, tables, table cells) is the most bugfree option yet is still sometimes handled in unexpected ways. Notably, in a flowing area most browsers interpret 100% as screen width, not rendering an image until the area is that wide, & doing the same for a table or actually rendering it in situ. This is why Ive contained the posts in a table cell which generally respects the 100% for use in scaling (although entailing issues with search engine visibility). The lone exception is Explorer which in a table cell actually interprets this as a percentage of the *image* itself. Proper scaling must be done with the IE proprietary conditional code & specification of width in pixels narrower than that expected in a hapless IE users session.

Arent you going to need an index?

Absolutely. But its just another HTML page I have complete control over. Like the lines in the shellscript above its just a bookkeeping task & should I choose to keep crossreferences explicitly by topic or date Ill just keep them uptodate by hand. This also implements flexibility over the entire document store in case the nomenclature conventions evolve or I wind up making other types of global changes.

Are you really prepared to upload potentially hundreds of regenned documents for every one character change in the sidebar code?

You bet. Even if the blog layout doesnt stabilise (which I doubt), 100 20K posts is still only 2M, & if the documents themselves havent changed, any inline images dont have to be uploaded again. My approach clones a bit more code but the resulting webpages are rock solid. & the fact is a onetime gen / upload is technically superior to a PHP/SSI expansion each time the page is served.

Are you serious about that server?

At this time Ive not used 50webs alot, but if they dont work out Ill just take the whole system & put it somewhere else. Their response time isnt that slow & their ftp access seems quite robust. Their 500K filesize limit wont affect a blog too much & I keep MP3s & big images elsewhere anyway. I particularly like the combination of *no ads* along with 60M of storage. Thats (eg) 3000 20K documents which is a fair amount of blogging. Maybe Ill write an article or two.