(with apologies about the length...)
Seems neat! I like the idea of just putting stuff in a directory and then getting a reference to it and using it. Can it do more than parse XML? How about YAML? What if it could load images?
XML only at the moment - I've never actually seen YAML used "in the wild" myself, I suppose it could be added but I see it making the API more complicated and harder to use with little benifit.
If you used something like XStream for XML or, even better
, YamlBeans for YAML, those libs serialize and deserialize object graphs without the need for a decoder, or even objects in the graph to extend a class.
I looked at using XStream but it wasn't a great fit. XStream aims to just convert to/from xml with as little effort as possible - Rebirth is about making your own xml syntax for resources and converting that into a set of objects with minimal parsing code. Obviously I've pinched the handy bits (like auto decoding of primative and array types) anyway so adding XStream as well doesn't make sense.
Progress is important. Probably less so with configuration files, since they probably parse quickly, but loading images, maybe building a database, etc. Should be a nice way to get a percentage of progress. If the framework has many tasks and some of them don't have an idea of completion percentage, then the progress percentage would be indeterminate. However, and this is the clever bit
, what if it remembered the time it took, so next time the app runs it will show progress percentage based on time.
It's already possible to determine loading progress over the top of the current system by looking at resource states. I plan on writing a better 'resource phase' system over the top for typical per-level style resource management which will have progress tracking.
Easy of use. Serialized objects shouldn't have to extend a class. The framework shouldn't require any setup, just files in a directory and some Java code to create a resource pool.
Rebirth resources don't have to extend a base class, but they do need to implement an interface so they can have their lifecycle managed. Trivial resources (which just use auto parsing) can extend a base class to get that behaviour 'for free'. For classes you can't control or implement an interface then Decoders let you use these easily.
Adding resource types should be easy. Eg, what if I wanted .sql files to be run in an in-memory database using the resource system in order to gain progress status and file watching? What if I wanted to do image loading via LWJGL? Via Slick? Audio loading?
The Rebirth approach to this is that you use your regular image/db/audio resources, and have a Resource which creates them in the create() callback. Main-thread callbacks let you do any initialisation which has to happen in the main thread (like texture uploads).
What happens if all my resources are in JARs? Might be neat to work from the file system, classpath, JAR, ZIP, URL, etc. Might want to make how the resources are found and loaded very flexible to support this sort of thing.
Native file system (for development) and jars (for deployment) are supported out-of-the-box. If you want to support additional locations like zip or over the internet then the ResourceIO interface lets you do that.
Might be nice to clear a resource pool. Imagine you had separate game screens that were very resource intensive. When you leave a screen you could clear its resources and when you show a screen you would load them again. Would be sweet if this were just a method call or two. Resources could be treated generically and have a lifecycle, so different resource types would have hooks to init/destroy/whatever.
See above comments on progress tracking.
How about a way to save resources? My config files can usually be changed in-game and are written back to disk. Maybe resources could even be added to a resource pool programmatically and it would create new files.
Config files and any savable state/progress isn't part of a resource system IMHO. Resources are very deliberately immutable, intended to be in a jar or on read-only media (CD/DVD). More of a job for something like XStream IMHO.
I think I should emphasise that Rebirth is not
XStream. They solve different problems in entirely different ways. I really would suggest giving it a try rather than picking apart the feature list - it's only a couple of function calls to get started and you'll quickly see easy it is to add and tweek resources. Plus, I'm much more likely to add/change things if you're using it rather than armchair debating it.