Remove seer integration

[tsherif]

No description provided.

[coveralls]

Coverage increased (+2.5%) to 83.907% when pulling 8f6ab0d on remove-seer into 150ca28 on master.

[Pessimistress]

Also need to remove the mentioning of seer in documentations.

[ibgreen]

I get that cuts are sometimes necessary.

That said it would be cool if there was a plan around the debug support in the frameworks - particularly if that plan made it clear that while some things are being phase out, the ambition is that the overall debug support will be getting better, or at least that maintainers are positive to accepting contributions in certain areas of debug support.

I obviously think strong debug support is valuable for a suite of GPU focused libraries, so here are some simple things that could go into a roadmap:

• The Stats/StatsWidget combo - an impressive high-potential recent addition to the overall debug support. A lot more could be done here to make it really useful - just a statement that there is ambition or interest in developing this feature would be great.
• Also the logging functionality in the library could use some work/docs.

More far out ideas:

• @probe.gl/bench - build more integrated bench-utils for deck and or luma to facilitate creating performance-focused test "benches".
• Right now a number of cool projects do "visual studio code" editor integrations, some of them quite impressive.
• One could even explore connecting deck/luma to tracing frameworks like Jaeger, etc. Both on the producing and consuming (visualization) side.

[Pessimistress]

If we could leave a hook here, something like LayerManager.callbacks.onInitialize, it will allow users to add back similar functionalities using an external module.

[ibgreen]

If we could leave a hook here, something like LayerManager.callbacks.onInitialize, it will allow users to add back similar functionalities using an external module.

I like that proposal! I am playing with the idea of setting up some open source "dot-gl" libraries from Unfolded's side that could contain some of the more experimental code that is being cut from the core libraries, plus some new stuff that we are developing that would be complementary to the existing frameworks.

That way the vis.gl core libraries could go ahead focus on being really small and hardened, but also provide the extensibility hooks so that we can continue to build out more experimental and advanced functionality (and if and when that matures we can always go back and make it official parts of the suite).

[tsherif]

Also need to remove the mentioning of seer in documentations.

Done.

If we could leave a hook here, something like LayerManager.callbacks.onInitialize, it will allow users to add back similar functionalities using an external module.

This could be cool, but I'd rather build a hook API like this around an actual usage so we know it provides something useful.

That said it would be cool if there was a plan around the debug support in the frameworks

Agree that it would be nice to put together a plan around this. I'd love to see things function more in the plugin style like luma.gl/debug so you don't pay any cost for a tool if you're not using it.

[ibgreen]

This could be cool, but I'd rather build a hook API like this around an actual usage so we know it provides something useful.

Well, the way I see it, seer was "actual usage". In my view, seer was actually very useful. And the deleted code shows exactly where hooks were needed...

[tsherif]

What I mean is if we want seer to be supported in this way, we should build and test seer support as a plugin, rather than just adding hooks and hoping everything works out.

[ibgreen]

What I mean is if we want seer to be supported in this way, we should build and test seer support as a plugin, rather than just adding hooks and hoping everything works out.

Yes that makes complete sense. With the caveat that it depends on how much work it would require signing up for, I'd be interested in helping out with that.