8 Sep
2015
8 Sep
'15
5:06 p.m.
On 2015-09-08 16:56, Sampsa Laine wrote:
On 8 Sep 2015, at 15:52, Mark Benson <md.benson at gmail.com> wrote:
Not that I want to discourage you guys, but it is not that simple.
For example, the VMS help files actually looks pretty much the same in
format as the RSX help files. However, where VMS have a rather
interactive help program, that will figure out the subtopics, list them,
and prompt you, the RSX help program does nothing like this. So, instead
each help topic itself needs to list what subtopics exist, in the help
text. So, in essence, while the information is there, you need the
resulting output content to be somewhat different.
Datatrieve is probably not what I'd use for this. This is a case of
wanting to have data in a format that identifies different types of
information, and relationship between them. But it's not really a
database as such. Datatrieve fits this usage pretty bad.
You could argument that something like HTML could work, just like XML,
or any other markup language.
But you need tools to generate output for different targets, which maybe
is the more complex part. Anyone going to write those? Else I think this
is not going anywhere.
You could, in essence, have a very simple source file format. Just
key,value pairs. That is the easy part. The generation of files is the
larger work.
Johnny
I need a DATATRIEVE expert... any volunteers? :)
Aside from that, MediaWiki might be the best idea for storage (even if
I'm not that keen on it) as it's easy to host and the front-end is
relatively platform agnostic.
My idea was to keep the "sources" in VMS HLP format and write some scripts to
convert them to whatever we need (including MediaWiki markup that I then automatically
upload).
This way people can access the information through various sources (Plain text files over
FAL, MediaWiki, VMS HELP, JSON for further processing etc).
Basically you describe the output format to me and I write the scripts to produce them -
the source file is copied across HECnet to CHIMPY which produces the various outputs,
updates the Wiki and possibly even notifies interested parties of updates made.
Sound like a plan?