Are you using the dmJson C++ api?

Announcements
#1

In an effort to improve on our internal apis, and the current functionality, I’d like to know if you are currently using our dmJson api?

The engine itself doesn’t need that api, and frankly, the implementation (jsmn.c) leaves a lot to desire in terms of performance. Also, the api itself isn’t great.

Our wish is to remove that api entirely, which would be a breaking change.

If our users are actually using the dmJson api, I’ll create a separate extension with that functionality.
(Personally, I’d use another C library entirely due to it’s poor performance)

Regards,
Mathias

7 Likes
#2

Ping @selimanac , I believe you’ve used the api before. Are you still using it?

#3

Nope, I’m using cJson native extension most of the time.

3 Likes
#4

How Lua api is going to remain if dmJson is gone?

#5

We’ll use another json parser that does the conversion lua<->string.
As such, we will still support json.encode()/json.decode()

We don’t need a DOM api to do that. In fact, a “sax” style parser uses less memory and is generally faster. We’ll likely use the lua-cjson library (which the defold-cjson is based on)

1 Like
#6

Got it.

#7

Only Lua API for me, but I guess if I would like to use something better I would go with a native extension then, but that’s only one opinion :wink:

1 Like
#8

No problem for me, because…

image
image
image

… I don’t know what you’re talking about.

7 Likes
#9

It would be a breaking change! YaGames, JsToDef plus a bunch of official extensions (Facebook, Push, IAP etc) use dmJson.

I see that all those extensions share almost the same piece of code (JsToDef vs IAP). So, if you write a short guide on how to migrate from dmJson to another lib, it will help a lot.

1 Like
#10

Correct.

This is why I wanted to know the scope of things.
Although we try to avoid doing breaking changes, it doesn’t mean we won’t do them when we feel we need to.

In the case of the dmJson API, it wasn’t really an api, and as such, we couldn’t really swap out the backend. Also, while doing this, I realized that the engine itself doesn’t actually need the api.

And, if we’re doing a breaking change, why not try to make the best out of it.

So, we’ll remove the C++ api (and we may implement a C++ api as an extension, but only if necessary, hence this post)

As for the cases you pointed out (there are several), we have changed the API somewhat for dmScript::JsonToLua() so that it doesn’t take the old dmJson::Document* pointer. As such, it will be a lot simpler (and faster!) to convert to and from Lua and the string:

int dmScript::JsonToLua(lua_State* L, const char* json, size_t json_len);
int dmScript::LuaToJson(lua_State* L, char** json, size_t* json_len);

Imho, it will make the code easier to read and maintain, and the main hassle of upgrading the extensions, will be the version numbers/releases (it’s easy to miss an extension that uses this api)

You can see the full pull request here.

5 Likes