I assume that means compiling with liberica more or less worked?

There are a few problems to think through. My guess is that the immediate problem you are running into is that there's not a good way to serialize compiled functions.

My suggestion is to spend some time thinking about what the API for the pod should look like given that compiled functions don't have a good way to be serialized.

Yes, compiling with liberica worked. About serialization of "complicated" objects (such as compiled functions), @borkdude dealt with somewhat similar issues in serializing DB connections in his SQL pods. The basic idea is to maintain a map of object -> string (which can be an UUID) and also string -> object for deserialization.

ok, so that means you have a solution to the problem you posted in this thread?

I have an approach to a solution. But I would like to do the thinking through that you suggested above before rushing to implementation. First, are all "complicated objects" that membrane deals with - compiled functions?

No.

java2d/run returns a map with some values that can't be serlialized

for example, the JFrame of the window created.

Other than java2d/run, I can't think of any other functions that deal with complicated objects besides compiled functions off the top of my head.

I know membrane.ui/image can accept BufferedImages, but you can just pass a file path or URL instead.

An unrelated topic: In other pods, they define a small number of pod functions that Babashka can invoke. In membrane, I implemented an approach in which I retrieve all objects defined in a namespace using ns-map. However I see that I get a very long of objects, some of which can be variables. How feasible is it for you to add a metadata to mark functions and variables that you want to make available to Babashka? For example ^pod-func to mark pod functions ^pod-var to mark pod variables

oh, and membrane.component/make-app accepts a var and maybe an atom, which might need special handilng

About the JFrame of the window created: We'll set a map in the pod side to translate JFrames into strings which will be transferred to Babashka side, and serve as proxies. When Babashka side sends those strings to the pod, they'll be translated back into JFrames in the pod side. The question - are JFrame and compiled functions the only "complicated" datatypes that we need to deal with?

https://clojurians.slack.com/archives/CVB8K7V50/p1710783639279229?thread_ts=1710759942.512309&cid=CVB8K7V50

> How feasible is it for you to add a metadata to mark functions and variables that you want to make available to Babashka? I could do that, but I'm not sure it's the best approach. If the pod needs a list of which vars should be exported, it should probably be included and maintained in the pod library itself.

If there are public functions that should be excluded from the pod interface, then it would be helpful to come up with a list of reasons why. It might make sense to mark functions based on their intrinsic properties.

Can I rely upon you to make the list of functions and variables to be exported by the pod to Babashka? It can be either in the form of: • objects with meta tags (and then I'll use ns-map with filter on the meta tags) • a proper list You decide. I can adjust my code to accommodate either.

I'm not that familiar with pods or babashka.

The list of functions exported by the pod should be maintained as part of the pod library. It should most likely be a subset of the public functions available

About "complicated" objects (JFrame, compiled functions, etc.) - is it possible to have a predicate to tell if an object is "complicated". When complicated, I'll add it to map of proxies and transfer only the proxy across the Babashka-pod interface. The proxy in @borkdude's SQL pods looks like this: {:podnamespace/proxy #uuid"something"}

I'm not sure you can tell if an object is definitely not serializable, but you can usually tell if an object is serializable.

https://clojurians.slack.com/archives/CVB8K7V50/p1710784362071449?thread_ts=1710759942.512309&cid=CVB8K7V50 I'll try to simplify for you the mental model of pods. The pod side includes the membrane library and manipulates objects. The Babashka side manipulates only basic Clojure data types and proxies for those objects. It tells the pod side what "complicated" operations to do with "complicated" objects.

Thanks for the discussion. I think I now have some idea what to do.

@U7RJTCH6J, I forgot to ask you - are the "complicated" objects, which you manipulate in membrane, immutable?

it depends on the object. usually not

functions: yes JFrame: no atoms and vars:no

When dealing with the mutable objects, are there reasons why does the Babashka side need to have an handle on the object? For example, when there are more than one JFrame in the application, and the Babashka side needs to manipulate one of them. When Babashka needs to manipulate those mutable objects, do we have (in pod side) any stable handle that we can use as a mapping key?

You can always create one by keeping a map of obj -> uuid

I need to ensure that uuid maps to the same object even when the object mutates.

I believe the maps will use the object's hash, which won't change.

I'll use (unless advised otherwise): number? string? char? keyword? symbol? list? vector? set? map? to identify "simple" objects. All other objects will be added to a map which transforms them into {::proxy (str (java.util.UUID/randomUUID))}.

for the collection types, you also need to make sure all of their values are simple

unless that's already being done by the serializer

Will test and see. Fun!