In appose-java you can now do:
Thing thing = service.proxy("something", Thing.class);and you'll have a Java proxy object that uses Appose tasks under the hood for its method calls.
This is neat, but this does not integrate at all with explicit task inputs & outputs. It would be nice if:
-
When passing a service-side object to the worker as an input, in case that object cannot be JSONified: instead of failing, a worker-side proxy object is created, which functions under the hood by special task.update calls back to the service process.
-
When receiving a worker-side object as output, in case that object cannot be JSONified: instead of failing, a thin WorkerObject instance is received, which knows its name and worker-side type, and can be proxied on the service side on demand using .proxy(Class<T> iface).
One open question: does it need to be configurable whether a particular object gets serialized versus proxied? I lean yes, but don't know how that API would look yet.
In appose-java you can now do:
and you'll have a Java proxy object that uses Appose tasks under the hood for its method calls.
This is neat, but this does not integrate at all with explicit task inputs & outputs. It would be nice if:
When passing a service-side object to the worker as an input, in case that object cannot be JSONified: instead of failing, a worker-side proxy object is created, which functions under the hood by special
task.updatecalls back to the service process.When receiving a worker-side object as output, in case that object cannot be JSONified: instead of failing, a thin
WorkerObjectinstance is received, which knows its name and worker-side type, and can be proxied on the service side on demand using.proxy(Class<T> iface).One open question: does it need to be configurable whether a particular object gets serialized versus proxied? I lean yes, but don't know how that API would look yet.