Separation of Concerns

[tyscorp]

In my opinion, it would be better if this library focused solely on parsing chunk blocks/packets. (and keyframes?)

The consumer (possbily another loldevs lib) should be responsible for maintaining game state/parsing input file formats/outputting results/etc.

Edit: I was going to put this in issue #7 but I feel it's important enough to warrant its own issue. This is more about the scope of the library.

[toulouse]

I agree, but while I've been busy @satan6 has been zooming a long and doing a lot of work so they've been given a lot of free rein over implementation. I'd actually say they've got a lot of say in the project for that reason.

Anyhow, the way I would like to see it (and not necessarily the "Right Way" or the way it should be done) is to have a core library that is for the most part stateless, and then a set of library "extras" that do the additional stuff like state tracking.

[themasch]

👍 for a "mostly stateless" core lib ( but thats just my opionion, so maybe +0.001 instead of +1 ;) )

[sathorn6]

Yeah i also agree, basically keep it at the level it is right now. But i think we should include the input file parsers like .rofl, our own zip-format, maybe .lrf and a way to decrypt raw chunks, so that we deal with all that low-level binary stuff and just provide nice packets.