So... really recently (in the past few weeks) elm_map broke. it can't seem to download map tiles from openstreetmaps anymore. Something changed/broke. I don't know what. I haven't dug in yet.
So we didn't break stuff... it appears OSM did. Now here are some thoughts: 1. We rely on a 3rd party on-line service for this widget. this service may change, break or shut down at any time. To fix this requires EFL updates every time this happens. This isn't really nice and sustainable as we basically would need to provide backports too and having to rev an entire toolkit to deal with http "api" changes is kind of nasty 2. Since this service can break or change at any time... is it wise for us to have such widgets. If it was a service we controlled then maybe it'd make sense as we'd be in control of it breaking or changing and can sync these, but still see #1 above for old EFl versions... So what do we do? Going forward do we deprecate elm_map and avoid such problem sin the future - if you want something that relies on a service like this it needs to be in an app or out of EFL/Elementary. We can provide the tools to implement such service clients, but not the actual service protocol etc. handling... ? Do we fix this at all? If we're going to deprecate - then in some ways OSM did that for us by breaking? Do we just make it formal and move on? If we are to continue doing this kind of thing do we either: 1. "proxy" such services from enlightenment.org thus *WE* run the service and ensure it stays up and we handle interfacing to OSM at the server level so we can keep providing compatibility to existing EFL things but deal with compatibility shims on the server? or 2. Move protocol handling out of the code perhaps into something like lua scripts and provide downloadable/updatable lua scriptlets from e.org whenever things break. this is a bit like youtube-dl I guess. We don't have to serve real data - just enough logic shim to let clients deal with it and update that shim as needed. Going forward this actually allows expanding this to cover lots of online services, but it comes with a few gotchas: 1. we need to handle signing and auth of those signatures to avoid man-in-the-middle attacks when clients try and update these scriptlets, 2. we probably need to create a very restricted sandbox "just in case" so clients can feel safe. Or well the other option is to stop doing this and accept it's too much work. ? -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- Carsten Haitzler - [email protected] _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
