| Cycle detection in URIConverter prefix expansion [message #1855829] |
Sun, 06 November 2022 23:54  |
|
I am looking at the code of UriConverter's normalization. It seems that it aims to reach a fixpoint by querying mappings repeatedly.
The underlying UriMap uses length-sorted prefixes. When adding new entries, there does not seem to be a check on the validity of the entry.
I am now wondering, if the converter will simply fall to the bottom at runtime with an SO provided prefix entries like this:
Or is there some structural check or occurs check that I have overlooked?Seems an easy configuration error to make.
I have not tested this. Thought asking the questions would be easier and also provided some implicit documentation.
|
|
|
| Re: Cycle detection in URIConverter prefix expansion [message #1855830 is a reply to message #1855829] |
Mon, 07 November 2022 00:04  |
|
Something like this
a:/ -> b:/
b:/ -> c:/
c:/ -> b:/
normalize(a:/boo)
trimmed = a:/boo
result = b:/boo
normalize(b:/boo)
trimmed = b:/boo
result = c:/boo
normalize(c:/boo)
trimmed = c:/boo
result = b:/boo
normalize(b:/boo)
trimmed = b:/boo
result = c:/boo
normalize(c:/boo)
trimmed = c:/boo
result = b:/boo
|
|
|
|
|
| Re: Cycle detection in URIConverter prefix expansion [message #1855837 is a reply to message #1855836] |
Mon, 07 November 2022 11:41 |
 Ed Willink
Messages: 7655
Registered: July 2009 |
Senior Member |
|
|
Hi Joern
There are many places where EMF could have a very nannyish implementation, but the occasional benefit for the idiot developer has to be compromised against an overhead for all users always. Perhaps there could be asserts to avoid production overheads.
However you are the developer and so you have the freedom / responsibility to code correctly. In my code, I have guards against my own stupidity / transitive opaqueness with at least a child stealing detector and crazy eGet/eSet checks.
I also use @NonNull/@Nullable extensively however the lack of EMF / platform declarations limits their benefits so that I sometimes wonder whether they cause more trouble than they save. Many EMF declarations can have external annotations to tighten up code.
Regards
Ed Willink
[Updated on: Mon, 07 November 2022 11:44] Report message to a moderator |
|
|
| Re: Cycle detection in URIConverter prefix expansion [message #1855856 is a reply to message #1855837] |
Mon, 07 November 2022 21:30 |
|
I guess what I am saying is, that not everyone is a developer. And EMF provides extension points for these expansion entries. Extension points are meant for people to contribute values while they have a local view and scope. They are meant to be independent component contributions. What is implemented here does not support this architectural view.
Personally, I feel saying the standard is "high-performance, self-documenting, don't be stupid" is a poor excuse for adding reasonable safeguards. I am not sure how the performance cost enters into this specific scenario, as one would expect a cycle of expansion to show very quickly. I take your point that it is on me if I want a pull request on this issue.
More likely than contributing though, I am at the moment inclined to recommend to my staff not to use this feature altogether and go around it. We have already had a leaning towards using EMC as our primary model abstraction, with EMF used for a limited scope. The argument above strengthens this point of view.
Thank you for explaining your perspective on design though. It helps with assessments.
Best wishes,
JG
|
|
|
| Re: Cycle detection in URIConverter prefix expansion [message #1855863 is a reply to message #1855856] |
Tue, 08 November 2022 08:08 |
Ed Merks
Messages: 33143
Registered: July 2009 |
Senior Member |
|
|
Joern Guy Suess wrote on Mon, 07 November 2022 22:30I guess what I am saying is, that not everyone is a developer. And EMF provides extension points for these expansion entries. Extension points are meant for people to contribute values while they have a local view and scope. They are meant to be independent component contributions. What is implemented here does not support this architectural view.
This strikes me as somewhat a contradiction. Someone specifying (developing?) an extension point is a developer.
Quote:Personally, I feel saying the standard is "high-performance, self-documenting, don't be stupid" is a poor excuse for adding reasonable safeguards. I am not sure how the performance cost enters into this specific scenario, as one would expect a cycle of expansion to show very quickly. I take your point that it is on me if I want a pull request on this issue..
High performance is never an excuse but rather a goal. Perhaps it's possible to check for cycles while modifying the maps, which is an infrequent operation so not performance critical, but normalization is a core operation (part of proxy resolution) that must perform extremely well. If such a map-modification check is super important to you, you are of course welcome to contribute such a thing. But, after 20 years of industrial use, I believe you're the first ever to want such a thing.
Quote:More likely than contributing though, I am at the moment inclined to recommend to my staff not to use this feature altogether and go around it. We have already had a leaning towards using EMC as our primary model abstraction, with EMF used for a limited scope. The argument above strengthens this point of view..
I've never once used the extension point in any project. The most likely use for such a thing is to redirect some logical URI to something physically located without your plugin; and in this case who would ever feel compelled to redirection your plugin location URI to something else. Rather they would redirect the logical URI to something of their own, not leading to a cycle.
But I do use redirections often. Even Ecore uses that programmatically for locating *.ecore models and Oomph uses it heavily for locating setups.
As for EMC versus EMF, if what appears to me a nit tips the balance, I have to wonder....
Quote:
Thank you for explaining your perspective on design though. It helps with assessments.
Best wishes,
JG
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
|
| Re: Cycle detection in URIConverter prefix expansion [message #1855889 is a reply to message #1855865] |
Wed, 09 November 2022 00:15 |
|
Indeed. EMC is Epsilon Model Connectivity. And the issue above is not the only point that leads to my preference for using it. In the Epsilon book there is a nice chapter about the industry experiences that led to EMC's design. I find the responsiveness to industrial needs quite positive. In particular, I find that EMF's interaction with other storage formats as resource is complex and my aim was to document that more thoroughly to enable easier adoption. This is important to me for use cases where we are using multiple models together in industrial workflows (toolchains, DevOps). This only works if my toolchain that I have composed from different model services works reliably. With the issue above, I cannot be sure of the behaviour of a composed system. I cannot suddenly have my production process fall down and go into debugging mode. It is more than a nit from that perspective. It may have been that in 20 years nobody has used EMF in an environment much larger and more automated then a one-person-desktop IDE. And maybe that is one of the reasons that has limited adoption at large.
Returning to EMC and 'the horrors underneath'. EMC deliberately forgoes proxy resolution and resource set management. This limits its use for compositional modelling and makes EMF/Ecore a preferential approach for larger systems. On the other hand, adaptations to third party libraries are more easily achieved giving EMC a far greater reach and scope. It seems to me that I should use EMF only with its XMI serialisation and standard configuration and not use its configurable resource mechanisms. However, that will require a fair amount of data replication.
As for the performance of the normalize method, I believe that simple memoisation should defend this well enough, much like you have already implemented (including structure modifications check!) in the MappedResourceLocator . However, I would only optimise after tests show a need. The stack overflow for the normalisation is guaranteed. I have a test for it now. Let's hope that we will have another 20 years of industrial use without anyone else ever having an issue.
Otherwise, at least there is your lucid explanation above as to the reason why this is not a concern. Everyone is a developer. Even if they are just filling in an extension point definition to add a help file.
Thanks for your detailed reply.
Best wishes,
JGS
|
|
|
Powered by
FUDForum. Page generated in 0.04173 seconds
] 
Search
Help
Register
Login
Home
