-
Notifications
You must be signed in to change notification settings - Fork 30
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Phase 3: encoding #20
Comments
Here are some notes/todo items: Use casesCommon use cases that the library must support:
It would be good to have small test programs for all use cases. They can be used for development to make sure use cases are supported and the interface is easy to use and later are the basis for tests and docs. Features
TODO
|
Thanks for writing this up @joto!
I'd be interested in helping out with this. I started working on mvt-fixtures (which is currently being used by this library) and can add more there. Also recognizing having fixtures in a separate repository might be a pain to maintain, happy to add some here. |
@mapsam I think having the fixtures in an extra repository is okay. Yes, a bit harder to use here, but easier to use across projects. Here are some things you can help with:
|
@joto I like the idea of improving how to describe fixtures, such as a JSON object. Could we use https://github.com/yinqiwen/pbjson to create protobufs from these JSON objects? |
@mapsam I was just thinking about using JSON as a way to encode some metadata about the tests not the test data itself. The test data can be created in many ways, for some it might be possible to use pbjson or something like it, for other we really need our own code where we can fiddle with the bits. Test data should be easy to create and we also want to make sure that we don't introduce too many dependencies. After all we don't want to test pbjson or anything like it but our own code, so it might be better to stick with tried and tested libs like the official Google protocol buffers libraries to create the test data. And for the tests we don't need the performance that a C++ lib will provide, maybe the convenience of a Javascript or Python library is better here. But feel free to experiment! |
This is really well articulated and would be very very valuable. I agree that it is critical to have the changes to make the tiles invalid be targeted, specific, and documented in code (so you could return when you think of another invalid change). I will add however that the random approach is also valuable in finding edge cases (fuzzing) things that would break with invalid input we can't think of and I noticed https://github.com/google/libprotobuf-mutator which could be used for that effort. |
Going to close this ticket as I think we are resolved on all the issues discussed above. To recap: The encoding implementation is done, thanks to @joto. We've decided it will live in a newly named repo that has no dependency on anything but The small, single-purpose/malicious fixture discussion has blossomed into mvt-fixtures 3.x. The suite is ready to use to add many more fixtures and we can track work there. See mapbox/mvt-fixtures#15 and mapbox/mvt-fixtures#21 The large/varied tile samples discussed above is not done, but would be easy to start working on if we had a ticket dedicated to the idea. So I've created mapbox/mvt-fixtures#22. |
This issue is to track overall discussion on the next phase of development for this library: encoding.
The previous phases were Phase 1 (enumerations) and Phase 2 (decoding) (landed in mapbox-gl-native in mapbox/mapbox-gl-native#9312 🎉 ).
The primary goals for the encoding implementation are:
Roles
/cc @mapbox/core-tech
The text was updated successfully, but these errors were encountered: