You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We are making more use of images now (directories, etc) - but there is no easy way to host an image. You either need something public (which sucks) or have something private (which is cumbersome if you release your driver to others).
Would be great if the SDK could host images from itself (or maybe make it wider and host any resource needed). That way as a SDK writer - I'd be able to do something like: deviceBuilder.addResource('images', './images/'); deviceBuilder.addImageUrl({ uri: '{images}/movie.jpg', label: 'Movie', ... }...)
The SDK would then take the URI in the addImageUrl and substitute the variable in the URI with the appropriate resource name and then prepend with the full hosting URL of the SDK
The text was updated successfully, but these errors were encountered:
For my own project, I've ended up writing a local image "hosting" service using mostly the packages already required by neeo-sdk (express, axios etc.). It caches, resizes and serves images on-demand from memory. It really took very little code to achieve. Adding something similar as an SDK feature or just an example would be quite manageable, I imagine.
We are making more use of images now (directories, etc) - but there is no easy way to host an image. You either need something public (which sucks) or have something private (which is cumbersome if you release your driver to others).
Would be great if the SDK could host images from itself (or maybe make it wider and host any resource needed). That way as a SDK writer - I'd be able to do something like:
deviceBuilder.addResource('images', './images/'); deviceBuilder.addImageUrl({ uri: '{images}/movie.jpg', label: 'Movie', ... }...)
The SDK would then take the URI in the addImageUrl and substitute the variable in the URI with the appropriate resource name and then prepend with the full hosting URL of the SDK
The text was updated successfully, but these errors were encountered: