Hello!
I received some replies privately. I think if there are emails about one
of the core components of Tizen, then they should be archived and
available to anyone now and in the future. This doesn't have to be the
dev list, but I think there is none which is more suitable, is there?
Anyway, let me summarize for the list. Tomasz agrees that documenting
the protocol is useful for clarity's sake. However, he would prefer to
keep the protocol Cynara internal. An asynchronous API will be provided
by the Cynara project itself.
Tomasz, I'm fine with that, if it meets the needs in a timely manner. So
let's talk about requirements:
* For glib-based services: using GObject type system, integrated
into an event loop chosen by the service, GCancellable for
canceling a request.
* For other services (dbus-daemon is the one I have in mind here
specifically): C API, a file descriptor for integration into
poll/select, a handler function whenever that file descriptor
changes states.
In terms of priorities, the lower level API is more important. I want to
look into patching dbus-daemon as soon as possible. It is not guaranteed
that this will turn out to be useful, though.
The other API is relevant for EDS, SyncEvolution and AMB, and thus all
future Tizen IVI release with Cynara enabled (and not just merely
present).
When can we discuss the asynchronous API, and when do you think it might
be available?
On Fri, 2014-07-04 at 17:56 +0200, Rafał Krypa wrote:
> We have already designedcache invalidation into the protocol.Although based
> on a different idea.
> Clients shall keep persistent connection to server's socket.When
> policy is changed on the server, it closes all connections with
> clients.Clients should detect that during next check and act
> accordingly (i.e. flush cache andquery policy from the server).This
> should work transparently for
> libcynara-client users.
Beware that the client may be waiting for a response when it gets
disconnected, perhaps even one which currently has an open user dialog.
Please cover the correct handling of this situation in your protocol
design, too.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
