search

loldevs / libOL

Reference implementation for League of Legends spectator dump decoding. Basically abandoned.
MIT License
13 stars 3 forks source link

Separation of Concerns #11

Open tyscorp opened 10 years ago

tyscorp commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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

sathorn6 commented 10 years ago

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.