Community
Participate
Working Groups
Connection is functionally complete but too slow for various application scenarios. We should come up with a more lightweight, polylind-based alternative, that still supports anchoring of start and end points as well as decorations, but neither routing nor interpolation.
We should have a discussion about this. I have something for this in mind for a longer time already. We can support routing and interpolation, but the solution deviates from the current anchor and bendable concepts. We could manage advanced features for the new concept in separate bugzillas. The name of the new concept could be "Wire". I believe it would make sense to start simple, but in the end we should support even more functionality than currently with Connection, i.e. n-to-m connections, jumps, joins, etc. As a matter of fact, a simple of version of such a wire was already implemented multiple times for different customers, but was unfortunately not ported back to the framework. Nonetheless, I believe, Alexander and Tamas, you should be able to look at the corresponding source code. I have additional information to share, however, not yet publicly. So, let us schedule a team meeting, please. Due to other responsibilities, my availability is restricted. I will notify you via Slack tomorrow, so that we can find a slot. Best regards, Matthias
I have already created a simple abstraction (by stripping down connection) that corresponds to what I had in mind for simple, "geospatial"-kind of applications. I named it Traverse and added it to FX as provisional-API, so you can already have a look. I will add or adjust corresponding policies and handlers to MVC.FX as well. If that abstraction fits to what you intended, then we now have a concrete starting point, from which we can evolve. If not, then we can evolve your vision in parallel, as long as we keep both provisional API, and see where it leads us. For me it would be totally fine to have different alternatives to or replacements for Connection, as there might be different use cases. My only constraint would be that we do not break existing API and keep it all provisional until we know where it leads us. We can of course schedule a team meeting to share our thoughts.
