Project direction about heroprotocoljs HOT 5 OPEN

Consider how https://github.com/nfarina/homebridge and https://github.com/KhaosT/HAP-NodeJS are separate and distinct.

HAP-NodeJS is Apple's HomeKit Accessory Protocol AND THATS IT. That's what I envision this library as. A straight single port, that gets updated every time they push out a protocol update.

Then, homebridge is the application/backend that uses the protocol. Then, on top of that, a third party front-end interfaces with homebridge, the back-end application.

from heroprotocoljs.

If this library (or the foundation/protocol/stormreplay library, whatever we are calling it) is going to be an automated build, it should be ONLY exactly what Blizzard/heroprotocol is. No documentation, nothing.

In this manner, we can build the javascript heroprotocol (again, I prefer heroprotocol, not heroprotocoljs) and put it right on npm from the automatic build script.

We write our own heroprotocol.js entry point (ReplayDecoder) into the application (one that doesn't require command line arguments, returns data how we want it (JSON?, emit?) ) and do automated pushes to NPM after vigorous tests. The build script would be responsible for adding keeping this clean.

The heroprotocol library would be the parser and nothing else.

from heroprotocoljs.

Agreed with @jnovack

The library in this case would be the essential building blocks of other ones - I've got a whole bunch of ideas floating around that I'll share here incase it inspires someone else:

• A more advanced game score GUI that auto displays after games as soon as the game is finished using NW.js. Just leave the app up displaying on a second monitor and it could process it as soon as the replay becomes available. Could compare metrics across games to show where your game improved.
• Tease out data points and regularly publish them somewhere (there's a couple I'm specifically interested in, such as "number of messages" and winrate, which should be easy to get at)
• Have an alternate upload site hotslogs where the data itself is released under a creative commons license and anyone is free to analyze it.

As @jnovack mentioned, it would be very desired to leave the output of the data structures as native to javascript and normalized as possible.

from heroprotocoljs.

I feel like making heroprotocol.js a faithful port and it being optimized and practical are two different things, am I wrong? This port is the most contact I've ever had with Python, but the original heroprotocol.py seems to just be a quick output tool, with "quick" as in "quick to use and get usable data to look at", not "practical and performant for massive parsing and extraction".

My inclination is to remove some overhead from heroprotocol.js like the the EventLogger and CLI, rework the ReplayDecoder, and make this file a pure library and API used by everything else to access the raw data efficiently.

Besides that, adding a heroprotocol-cli.js that mimics the original heroprotocol.py on the root directory, and higher order tools and abstractions in bin/ and lib/ until they deserve dedicated projects or someone creates something better elsewhere?

I'm worried about fragmenting the codebase between different projects this early but it's something I look forward to if this project gains in popularity or it becomes clear it's needed at some point.

I think I'm going to look at port automation of remaining and future protocols soon because it seems needed to efficiently keep track of data structure changes between builds/patches.

I don't think going beyond basic abstraction by providing analysis tools has a place on this repository though, but @ajbdev if you want to start something it would be great to figure out what is required out of this library and it's current limitations.

from heroprotocoljs.

My interpretation is the same as yours on heroprotocol.py, it's just a helper script and a quick and dirty implimentation OF the protocol (just happens to be in the same repo)

The "faithful port" (to me) was each of the protocol files, that's where the meat and potatoes are. The entry point into the protocol files (heroprotocol.py) I do NOT consider part of the "protocol" and thus in order to make it streamlined that's the only piece we would write.

We know what the data looks like, rather than write it to disk (heroprotocol.py), we return it or emit it up to the calling application.

Or if you want to be "more" faithful, keep heroprotocol.py and we write the real NodeJS entrypoint as index.js. This way, the repo is a faithful port, but our abstraction library (index.js) is what is being used when we npm install heroprotocol as a dependency.

from heroprotocoljs.