About Time the 7 Year Old JavaScript Engine was Brough Up to Date - JSON et al

[wikitect]

JSON - JavaScript Object Notation (http://json.org) - provides a means to exchange model elements as name / value pairs. It makes it easy to export / import models and todays browsers provide native support because they use a modern JavaScript engine.

Wikipedia - https://en.wikipedia.org/wiki/JSON

JSON is a much better option for exporting than simple CSV because it allows an object/element/connector properties and values to be exported with the object/element/connector. Doing this with CSV is needlessly hard (because CSV wasn't designed for this). JSON is also an increasingly common interchange format - it is a defacto interchange standard.

Enterprise Architect, however, as it stands does not have the capability within its JavaScript engine to generate or parse JSON (without bespoke code which negates the point of a standard).

The reason for this is that EA uses the very old Mozilla SpiderMonkey 1.8 (http://mdn.beonex.com/en/SpiderMonkey/1.8.html) JavaScript engine. This is something like 7 years old. JSON was first introduced at 1.8.1. The Sparxians are aware of this but there is nothing it seems in the pipeline to update the JavaScript engine.

The JavaScript really does need to be brought up to date in line with the functions that are offered by todays browsers - JSON is likely not the only casualty of using an out of date JavaScript engine. If the engine were updated it would provide EA with the capability to generate/ parse models in JSON so that EA could play with other than just UML tools that understand XMI.

Isn't it about time this was brought up to a modern standard?

[qwerty]

When we are at it: replace the crude scripting for code gen etc. with some standard language. Replace the interpreted C-like shape script language with some (JIT) compiled standard language.

CSV has the advantage (if people did stick to the RFC) that it can be read with spreadsheet programs. They don't support JSON :-/

q.

[Eve]

wikitect,

Yes, it would be nice for users to have the extra capabilities provided by a more recent version. Unfortunately, it's never that simple...

Every library upgrade comes with the potential for incompatibilities. In this case I can see at a glance that it comes with additional dependencies that would cause even more upgrade drama.

qwerty,

Aside from your hijacking of this thread, just to be clear of what you are proposing. For any of the internal languages, ignoring the time spent to develop and test a new solution, the two options would be:

• Drop support for the existing language and work only on the "new" language in the future. Effectively invalidating every shape script / code template / transform that we or users have written
• Maintain two separate languages long term

How well does the perceived benefit of a "standard" language compare to the cost for either of those options? I'm yet to see an argument that comes close to justifying it, and I'd personally love to see improvements in that area.

[Glassboy]

Aside from your hijacking of this thread, just to be clear of what you are proposing. For any of the internal languages, ignoring the time spent to develop and test a new solution, the two options would be:

• Drop support for the existing language and work only on the "new" language in the future. Effectively invalidating every shape script / code template / transform that we or users have written

Obviously stupid.

• Maintain two separate languages long term

How well does the perceived benefit of a "standard" language compare to the cost for either of those options? I'm yet to see an argument that comes close to justifying it, and I'd personally love to see improvements in that area.

If you own the code base, it's mature, and you're able to maintain it in your development environment this isn't a particularly expensive proposition.

The risk you're carrying is a competitor turns up who focuses on the areas where EA is weak and eats a big section of your market.  By its very nature there's very low lock in with EA as a tool and people can keep using it indefinitely to access old material.

Your revenue is in new sales and maintenance licences.  The most common reason I hear for people not wanting to buy EA is that the output isn't very pretty.  Hell I've seen people buy $10,000 per seat products because they were pretty and then be stuck not being able to do things that EA does with ease.  And that's just the shiny stuff.  Your competitors are getting the jump on with value adds like common data models and implementing frameworks like BIAN.

[Eve]

Your revenue is in new sales and maintenance licences.  The most common reason I hear for people not wanting to buy EA is that the output isn't very pretty.  Hell I've seen people buy $10,000 per seat products because they were pretty and then be stuck not being able to do things that EA does with ease.  And that's just the shiny stuff.  Your competitors are getting the jump on with value adds like common data models and implementing frameworks like BIAN.

Exactly. I'm yet to see a situation where a purchasing decision was based on the language used to write extensions. Your own argument suggests that any effort to replace a working solution with something equivalent would be misdirected. That it would be better to extend what we already have to implement the various frameworks and languages that people are wanting to use.

[Glassboy]

Your revenue is in new sales and maintenance licences.  The most common reason I hear for people not wanting to buy EA is that the output isn't very pretty.  Hell I've seen people buy $10,000 per seat products because they were pretty and then be stuck not being able to do things that EA does with ease.  And that's just the shiny stuff.  Your competitors are getting the jump on with value adds like common data models and implementing frameworks like BIAN.

Exactly. I'm yet to see a situation where a purchasing decision was based on the language used to write extensions. Your own argument suggests that any effort to replace a working solution with something equivalent would be misdirected. That it would be better to extend what we already have to implement the various frameworks and languages that people are wanting to use.

Well Qwerty did say Replace the interpreted C-like shape script language with some (JIT) compiled standard language., and that's all about the pretty.

[qwerty]

It's Henry Ford who's said to be the originator of this epitaph: “If I had asked people what they wanted, they would have said faster horses”. Another epitaph of Indian origin: Once you recognize you're riding a dead horse you should dismount. However, there are plenty of alternatives.

q.