Date   : Fri, 24 Aug 2001 00:57:13 +0200
From   : "Mark de Weger" <mark@...>
Subject: Re: Online BBC Games database

Robert Schmidt wrote:
> It brings be to another twist on the XML topic, though:
> If an emulator (or front-end) is URL-oriented in its game oriented file
> accesses (with appropriately smart caching), it doesn't matter whether
> the XML+game related binary files reside on your local harddisk or any
> web server.  The base URL only changes from file:// to http:// (or even
> ftp://).  Broadband users could run their emulator (or front-end) with
> instant access to all game info and data, without having done a single
> manual download!
>
> After this has been made possible, one would like the ability to
> synchronize one, some or all entries between the local harddisk and the
> remote server.  The users could also opt to keep all XML data locally,
> but access all binary data (disc images, scans or docs) remotely, or
> even vice versa.

This brings me to another point we'd have to resolve and which I already
struggled with when designing BeebEF: the directory structure.

Obviously, the designers and administators of the XML structure and the Web
server would/should be free about the directory structure in which software
and related stuff are stored at the server (they could even use a database).

However, it is not obvious what the directory structure at each user's
(client) computer should be. Probably everyone has their own favourite
structure. Therefore, BeebEF currently does not impose any structure (other
than that screen shots and box cover images should be in the same
directories as their associated games). This makes it flexible, but makes
setup a bit more time-consuming. (You explicitly have to specify  in BeebEF
each publisher and game you have on your hard drive and then you have to
manually set up the hyperlinks to all documents related to a game.) By
imposing a standardized directory structure, BeebEF could be much easier to
setup, but less flexible. (For example, have a directory called "BBC Games"
and have subdirectories for each publisher. Each subdirectory could then
contain one disk image for every game. In that case you could just tell
BeebEF: "Import all publishers and their games, where the names of the
publishers and games in BeebEF are identical to their directory/file
names".)

This was already an issue for the current BeebEF, but it will become much
more of an issue if you want to detect whether files are synchronised.
(Obviously, you could keep a log file from the moment a user synchronises
for the first time, but this method would disregard the software and docs
the user already has before the first synchronisation. It would also
disregard all changes the user makes afterwards to their stuff without
synchronising.) If each user has their own directory structures,
synchronisation would involve a lot more than (intelligently) changing
http:// to file:// and vice versa.

And to make matters even more complicated (but now I'm really speculating
about something we'll probably never implement), it  would be great if
synchronisation would be both ways, also allowing for users to upload their
own stuff to a Web server, which others then can download again.

> Mark, I think a pretty general XML structure should be sufficient.  All
> the data types you mention are user oriented, and they're probably just
> as well off using the same tag.  How about an additional optional tag
> within doclink:
>
>     <doclink>
>        <name> ... </name>
>        <url> ... </url>
>        {<category>[manual|cover|map|screen|...]</category>}
>     </doclink>

This seems an excellent idea. Can we hire you? :)

Mark.