Any file on Windows (and Unix for that matter) has to be re-written; you can't add a record without doing that. Database tables are also stored in files, so same problem.
So in this respect, XML is no worse than ODBC, except that ODBC is more likely to be optimized than home-grown XML handling routines.
Umm.. Wrong. ODBC doesn't load the entire thing into memory, then keep it there until you need to save it again (though it may cache large sections for quick access, while writing "new" data back to disk immediately). That is the problem with XML. Databases "do not" re-write the entire file. They write distinct chuncks of data to the file as needed and don't compress the file to a smaller size unless you run them through a cleanup tool to sort of defrag the empty spaces. This means if it deletes the 90th record in a 10,000 record file, then the next record gets inserted into the hole, but, if the insert is at position 54, *only* records 53, 55 and the hole are written to, for some types, others may have the drivers sort things out to maintain some consistent structure, in the background. Kind of depends on the type of system in use. In the case of a map, all records that are "known" to have back-links to the room need to be updated, along with the room. Usually that means only two records, since there is no why to be 100% sure that all exits have returns, just the one that you just came in from, and that isn't always certain (being the reason why making mappers is a pain in the ass). While some languages, like the old QuickBasic, allow you to write in binary mode and thus read/write data from specific points, just like with a database, most file types that are meant to function as documents, like XML, have no fixed block size, so there is no way to index specific points in the file. You are forced to load 100% of the file into memory, then write 100% of that file back out. Speed isn't the issue, because, unless you re-read the file every time to look for the data, the entire contents of the file is already in memory, in a form that can be searched far more quickly.***But*** it makes it more volitile, since any crash, power outage or other problem will trash all your new data. Not a problem here, but if this project where to be expanded to a mapper, instead of just a map displayer, it wouldn't be a good solution any more.
That said.. Never heard of Kylix.. However, its companion CD apparently comes with the ODBC system also found here:
Well.. The proprietary version anyway.
Hmm. Seems you are using Linux here. Just realized what Kylix is. :p That complicates things by a huge margin. Its probably still possible, but the main problem won't be making it work on Windows, but connecting to the ODBC on Linux. I had kind of assumed that since you have an exporter application, you should be able to use it anyway. I mean, how are you reading the database in the exporter if not using the ODBC system? Unless that was written by someone else?
Oh, and your friends problem with UDP. Could it have been something in their firewall? UDP is unrealiable as is anyway. To use it effectively as anything but a general announcement system you kind of need to build a clone of TCP/IP over top of it. The underlying concept is the same in both, TCP/IP simply has checksums, response codes, the ability to repeat packets if one goes missing, etc. None of which UDP does on its own. As you found out, its not even capable of something as simple as, "I can't get there from here!" To do any of that the coder has to invent his own response codes, repeat codes and verification systems.
I can see, using Kylix, why there might be some issues with trying to support the COM interface instead, as well. Unless Borland is calling its Windows compiler Kylix as well now, you don't really have access to that. What we need eventually is something that runs in the same OS architecture as Mushclient, so they can talk to each other efficiently. UDP won't do it without heavy modification, TCP/IP is only workable if you don't mind cluttering up the client with extra windows. One extra is needed, at least, for each open world that uses the mapper, not the mention any other similar stuff people come up with later. That's not exactly efficient. ;) Maybe what we should try for is a more open project, something where those that know how to get the ODBC and COM connectivity to work can be helped by your expertise in managing to get a working graphical map.
Though, I don't know C++ well enough to write "Hello world!", so am probably not one who should be complaning much.