> It might be more complicated: different server configurations may
> access the same data, in which case locking just the configuration is not
> enough. We would also have to lock the underlying data bases. I expect
> this to get tricky quickly, which is why I suggested to implicitly serialize
> *all* kinds of accesses.
Yes, providing different kinds of accesses is a good way to improve scalability.
IMHO, besides, we'd better partition resources into many sub-parts and each-part
has its own lock so that for exclusive locking, some race conditions could be
avoided,
though this could lead to be more complicated .
This covers about 'session' topic. As I know, we'll also cover dbus api for
sync server side
for direct sync, automatic sync, and others, according to your previous
discussion.
Will dbus-api design cover all of them by the end of this week?
Cheers,
Yongsheng
-----Original Message-----
From: Ohly, Patrick
Sent: Monday, August 24, 2009 9:54 PM
To: Zhu, Yongsheng
Cc: SyncEvolution
Subject: RE: [SyncEvolution] next generation syncevo-dbus-server
On Mon, 2009-08-24 at 13:41 +0100, Zhu, Yongsheng wrote:
> > I therefore suggest that we model the new API and implementation
> around "locking" of a server configuration. Each lock request creates
> > a org.syncevolution.sync interface instance on D-Bus. That instance
> remains active as long as it has clients or a sync is running.
> Clients
> > can disconnect and reconnect to such an active instance. In that
> sense they are not exclusive.
> I'm a bit unclear about this paragraph. Here is my understanding.
> syncevo-dbus-server generates a unique interface for each server
> configuration. Any client who want to read/write/update it needs to
> use this interface. In such case, we could apply a lock for this
> interface to implement a 'around locking' for server configuration.
It might be more complicated: different server configurations may access
the same data, in which case locking just the configuration is not
enough. We would also have to lock the underlying data bases. I expect
this to get tricky quickly, which is why I suggested to implicitly
serialize *all* kinds of accesses.
> Right? If yes, I have one question: This interface should be
> generated dynamically. I wonder how this interface is notified to
> those clients who do not get the signal sent by syncevo-dbus-server?
The global org.syncevolution interface could have a signal which
announces such dynamically created interfaces. We might also use the
signal that the D-Bus daemon itself sends out when a new object
registers itself (haven't checked that yet).
> Another issue is that you mention 'not exclusive'. I consider it true
> only when instance broadcasts status/progress information. Otherwise,
> like update, it should be exclusive.
Then we need some kind of protocol that determines which client "owns"
the instance and is allowed to send commands to it. This may be useful
for dialogs which need to get the user's attention: we don't want n
clients to pop up n dialogs which all contain the same question.
However, for other operations which are provided as buttons or menu
items like "abort" or "suspend" it would be nicer to let the user decide
which interface he wants to use to submit the command.
> > The server needs to know how long it should wait for a reply before
> proceeding with some default operation. This depends on the kind of
> > clients which are connected: with no client connected, it should
> wait for a certain amount of time, because a client might show up.
> With
> > just the command line client connected, it should proceed
> immediately because that client is not going to ask questions (at the
> > moment...). With the sync-ui connected, it should wait for the
> sync-ui forever.
> What mechanism do you use for finding clients? Using Dbus standard
> interfaces to get registered DBus connections?
No, the clients would have to register explicitly by calling a D-Bus
method in our own interface.
> > Locking a config can be rejected immediately or queued, depending on
> what the client wants. An incoming connection request would be queued.
> I want to know what algorithm you use to handle incoming connection
> requests, First in first serve? Does any incoming connection request
> has higher priority than others, such as GUI client?
Good question. I think a priority queue would be useful, with higher
priority for GUI clients.
> > Locking requests can be removed by clients, time out or become
> obsolete when the client disconnects unexpectedly.
> So a client need request a connection before doing any request, like
> locking? Or if a connection request is accepted, the locking by that
> client is actually applied?
The later: the client requests a lock and is notified once that lock has
succeeded.
> Could you help show me a more detailed general process when a client
> wants to update or write the server config?
1. client requests lock for server "foo"
2. request is queued and granted at some point by server
3. the client now owns an interface instance which has methods for
editing the config, starting a sync, backup/restore
4. the client makes one or more config changes
5. the client saves those changes and releases the interface
--
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.
_______________________________________________
SyncEvolution mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution
