Alpha-2 mthd signature changes, user data ptr

[oetyng]

The xamarin projects have updated the NativeBindings methods to not receive the user ptr anymore.
So for example creating an MD would not take that parameter.

But when I look at mdata_info.rs in alpha-2 branch in client libs it still takes this parameter.

How is this working?

I am probably missing something here, just don’t know what?

Edit: I think I found it in last update (Oct 5th):

Earlier this week, we finally merged the dev branch to master. From now on, we’ll be continuing all current development on the master branch. This makes the current FFI API incompatible with the Alpha 2 release

This is it, right?

Edit 2: Arr… It just hit me… I won’t be able to test my stuff.
When can we have some win64 dlls for client libs? :
Edit 3: (snip, a bit too annoying gif)

[Viv]

@oetyng

The xamarin projects have updated the NativeBindings methods to not receive the user ptr anymore.

So for example creating an MD would not take that parameter.

But when I look at mdata_info.rs in alpha-2 branch in client libs it still takes this parameter.

How is this working?

I am probably missing something here, just don’t know what?

The NativeBindings isnt the managed language API in this case, thats just the files such as Mdata.cs, Session.cs and so on. The NativeBindings is merely the bindings and the userdata is used to pass the managed language callback as a passthrough to the C API and is encapsulated from the managed layer as it isnt relevant to the pure Managed language layer. When the APIs used by the App layer gets extracted to a nuget package(currently in works. not sure when its going to be complete) the public API from that package would be what the Mdata/MDataInfo/Session/… files expose, not the NativeBindings itself. so user usage would ideally resemble what you find in AppService.

@oetyng

This is it, right?

Maybe, but the mobile project/desktop projects are compiled against the published safe_client_libs package in crates.io and not against tip of tree anyways, so changes in tip of tree shouldnt matter until they get published and these applications use those versions.

@oetyng

Edit 2: Arr… It just hit me… I won’t be able to test my stuff.

When can we have some win64 dlls for client libs? :

When the safe_app package is published to nuget, we’ll be aiming to get it to comply with PCL 44, but likely in small steps where the mobile ones which are already functional getting supported first and the desktop platform bait and switch dll’s getting added in with corresponding tests.

[oetyng]

Thanks for the quick response!

Aah, yes the C API layer, forgot about it
So, in that layer that parameter is retrieved and passed to rust layer?

I have now a .NET Core2 application (it runs cross platform) that would consume safe_app. (Could I use the .so files for Linux and for iOS the .a files?)

I would just need a .dll for winx64 to be able to run it on my machine

Maybe I could compile it my self from sources if it is not coming soon?
Have installed rust too, but have never used it.

[Viv]

@oetyng

Aah, yes the C API layer, forgot about it

So, in that layer that parameter is retrieved and passed to rust layer?

It’s not passed to rust. it’s a pass through pointer which will be handed back to the caller(managed layer). It’s to hold state by the caller when dealing with the native ffi API in this case the managed layer delegates are referenced by it.

@oetyng

(Could I use the .so files for Linux and for iOS the .a files?)

Both libraries are for mobile, so the .so is for android not linux.

@oetyng

Maybe I could compile it my self from sources if it is not coming soon?

Compiling the ffi libs on desktop should certainly be possible and simple enough. When it’s going to be coming out as part of the nuget package, I dont know yet. Once it is out, we’ll certainly be mentioning it in the Dev update. To cater for the full PCL 44 spec and a standalone package for .net, there might be other requirements that desktop platforms will also have to support like url manipulations between app and authenticator which can be achieved via the system_uri crate to keep it in sync with the other desktop apps, but yeh these are all things that is currently being worked on, so “sometime hopefully soon” is going to be my guess for now.

[oetyng]

@Viv

Compiling the ffi libs on desktop should certainly be possible and simple enough.

Ok! I will have to look into how I could do that.

@Viv

To cater for the full PCL 44 spec and a standalone package for .net

I have now written a .NET wrapper placed in a .NET Standard library. So, it’s decoupled from my app. The point was that anyone could include it and they’d be off quickly to building apps. So, with that I mean to say that I was hoping that people could start even before you have a standalone package.

I just took the mobile projects code and did some small adjustments.
So, all I need now is the specific Ffi alpha-2 binaries for the various platforms.

So the best thing for .NET developers to do, which I am doing currently, is to develop .NET Core2 apps, since they can run on Linux, iOS, Win and in preview also ARM!

But I guess, for now I can just upload the wrapper to GitHub, and so anyone who wants to use it could look for the binaries, and if I manage to compile them myself I can upload them too.