Page 1 of 1

Abstracting file types

Posted: Thu Mar 02, 2006 8:50 am
by Maarc
As part of the ToolAPI project, I've noticed that we have a few different ways of storing things. Unfortunately, we can't just bust out with a standard ScriptSection to read each of the files.

The few that come to mind are:

* Accounts
* Books
* Messageboards

Accounts is very similar, but slightly different syntax. Books are fairly proprietary, and from a quick glance, msgboards seem a little proprietary as well.

What I suggest, and this won't matter for a couple of weeks, but I think we should standardise on a format. Same heading formats, same tag delimeters, and so on. Once we have the old stuff properly encapsulated, we can write a quick converter (and this would mean a C++ implementation of the ToolAPI as well).

But I would suggest, from a simple maintenance perspective, that long term we standardise on a format.

Just an idea, folks.

Posted: Thu Mar 02, 2006 9:37 am
by giwo
Standardizing a format would be fine...

Currently the layouts are different only because they were modeled after the original files when I rewrote them. Basically we store the data (in the case of the message board and books) in a very similar way to the packet structure from the client.

Posted: Thu Mar 02, 2006 11:41 am
by Maarc
Thinking on it a little, we may not even need to (though some of it, like accounts, could be fixed up to be the same style). Books and messageboards are good cases to keep the same, so that we can make it a little more packet friendly. But others, like accounts and such, don't really need to be put that way.

And I also just thought ... I intend to actually backport some of this to C++ anyway, to generate a C++ version of this ToolAPI as well. And if it's all abstract through that way, we could probably actually use it within UOX3 itself. One implementation, multiple ways to share it sort of thing. Which, if everyone uses an API, means it doesn't really matter too much (and we get a wider base to test against, as it's used in multiple locations).