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.
Abstracting file types
-
Maarc
- Developer
- Posts: 576
- Joined: Sat Mar 27, 2004 6:22 am
- Location: Fleet, UK
- Has thanked: 0
- Been thanked: 0
- Contact:
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).
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).