| 2010-08-22 21:35:41 |
Mikkel Kamstrup Erlandsen |
bug |
|
|
added bug |
| 2010-08-22 21:35:58 |
Mikkel Kamstrup Erlandsen |
dee: importance |
Undecided |
Wishlist |
|
| 2010-08-22 21:35:58 |
Mikkel Kamstrup Erlandsen |
dee: status |
New |
Triaged |
|
| 2010-08-22 21:35:58 |
Mikkel Kamstrup Erlandsen |
dee: assignee |
|
Mikkel Kamstrup Erlandsen (kamstrup) |
|
| 2010-08-30 11:50:35 |
Mikkel Kamstrup Erlandsen |
summary |
Transaction based DBus API for Dee |
Optimize DBus API for Dee |
|
| 2010-08-30 11:57:37 |
Mikkel Kamstrup Erlandsen |
description |
Currently the DeeModel DBus protocol has signals RowsAdded, RowsChanged, and RowsRemoved. This means that we can not support transactions in the wire protocol as well as many ops require two dbus messages. For example in the case of updating Unity search results we first fire off RowsRemoved to invalidate any non-matching rows, and then a RowsAdded with the new hits.
We need a protocol where this can be done in one message. I am thinking one signal like:
Commit(av row_data, au positions, au change_code, at seqnums)
Here row_data, positions, and seqnums are as in the current protocol, but the new arg 'change_code' is an enumeration with the values:
0: Add
1: Change
2: Remove
All the arrays in the Commit signal *must* have the same length, and like we also have currently in the protocol the positions vector is applied sequentially with each offset taking into account any previous row changes in the transaction affecting rows before it.
This would also mandate two new GInterfaces; DeeTransactionalModel and DeeTransactionModel that this builds upon. The transactional model could have one new method:
DeeTransactionModel dee_transactional_model_begin_transaction (DeeTransactionalModel *model);
And DeeTransactionModel is a proxy model (extending DeeProxyModel to help the impl) that buffers changes until someone calls:
void dee_transaction_model_commit (DeeTransactionModel *transaction);
In order to cancel a transaction one would simply unref the transaction.
FIXME: This approach would incur a lot of memory reallocation (all ops are essentially done twice). Perhaps the are clever workarounds... |
TRANSACTION BASED PROTOCOL
Currently the DeeModel DBus protocol has signals RowsAdded, RowsChanged, and RowsRemoved. This means that we can not support transactions in the wire protocol as well as many ops require two dbus messages. For example in the case of updating Unity search results we first fire off RowsRemoved to invalidate any non-matching rows, and then a RowsAdded with the new hits.
We need a protocol where this can be done in one message. I am thinking one signal like:
Commit(av row_data, au positions, au change_code, at seqnums)
Here row_data, positions, and seqnums are as in the current protocol, but the new arg 'change_code' is an enumeration with the values:
0: Add
1: Change
2: Remove
All the arrays in the Commit signal *must* have the same length, and like we also have currently in the protocol the positions vector is applied sequentially with each offset taking into account any previous row changes in the transaction affecting rows before it.
This would also mandate two new GInterfaces; DeeTransactionalModel and DeeTransactionModel that this builds upon. The transactional model could have one new method:
DeeTransactionModel dee_transactional_model_begin_transaction (DeeTransactionalModel *model);
And DeeTransactionModel is a proxy model (extending DeeProxyModel to help the impl) that buffers changes until someone calls:
void dee_transaction_model_commit (DeeTransactionModel *transaction);
In order to cancel a transaction one would simply unref the transaction.
FIXME: This approach would incur a lot of memory reallocation (all ops are essentially done twice). Perhaps the are clever workarounds...
MORE OPTIMIZED MESSAGE ROUTING
In the DeeModel protocol we use for Maverick the DBus signals RowsAdded/Removed/Changed does not pass the swarm name they apply to. This means that each swarm member must keep track of all swarm members and subscribe to their signals. Which means installing a new match rule for each swarm member and doing a lot of book keeping in the code.
If we instead mimicked what we already do in the DeePeer protocol we could pass the swarm name as the first argument of the signals. This way swarm members need only ever install one match rule ala:
interface='com.canonical.Dee.Model',type='signal',arg0='$swarmname'
This match rule would pick up all signals relevant to that swarm and nothing else.
PEER -2-PEER DBUS
In GDBus it's fairly easy to set up a peer-2-peer connection. This should save us the extra socket roundtrip we have when the DBus daemon is involved.
|
|
| 2010-11-15 14:51:54 |
Mikkel Kamstrup Erlandsen |
dee: milestone |
|
0.5.0 |
|
| 2010-11-16 06:17:07 |
Mikkel Kamstrup Erlandsen |
dee: importance |
Wishlist |
Medium |
|
| 2010-11-16 13:49:04 |
David Barth |
bug task added |
|
unity |
|
| 2010-11-16 13:49:09 |
David Barth |
unity: status |
New |
Triaged |
|
| 2010-11-16 13:49:16 |
David Barth |
unity: importance |
Undecided |
Medium |
|
| 2010-11-16 13:49:23 |
David Barth |
unity: assignee |
|
Mikkel Kamstrup Erlandsen (kamstrup) |
|
| 2010-11-16 13:49:34 |
David Barth |
tags |
|
backlog |
|
| 2010-12-01 13:59:40 |
Neil J. Patel |
unity: milestone |
|
3.4 |
|
| 2010-12-02 10:15:33 |
Mikkel Kamstrup Erlandsen |
dee: status |
Triaged |
In Progress |
|
| 2010-12-02 10:15:36 |
Mikkel Kamstrup Erlandsen |
unity: status |
Triaged |
In Progress |
|
| 2010-12-02 10:15:53 |
Mikkel Kamstrup Erlandsen |
branch linked |
|
lp:~unity-team/dee/gdbus |
|
| 2010-12-09 12:04:00 |
Mikkel Kamstrup Erlandsen |
description |
TRANSACTION BASED PROTOCOL
Currently the DeeModel DBus protocol has signals RowsAdded, RowsChanged, and RowsRemoved. This means that we can not support transactions in the wire protocol as well as many ops require two dbus messages. For example in the case of updating Unity search results we first fire off RowsRemoved to invalidate any non-matching rows, and then a RowsAdded with the new hits.
We need a protocol where this can be done in one message. I am thinking one signal like:
Commit(av row_data, au positions, au change_code, at seqnums)
Here row_data, positions, and seqnums are as in the current protocol, but the new arg 'change_code' is an enumeration with the values:
0: Add
1: Change
2: Remove
All the arrays in the Commit signal *must* have the same length, and like we also have currently in the protocol the positions vector is applied sequentially with each offset taking into account any previous row changes in the transaction affecting rows before it.
This would also mandate two new GInterfaces; DeeTransactionalModel and DeeTransactionModel that this builds upon. The transactional model could have one new method:
DeeTransactionModel dee_transactional_model_begin_transaction (DeeTransactionalModel *model);
And DeeTransactionModel is a proxy model (extending DeeProxyModel to help the impl) that buffers changes until someone calls:
void dee_transaction_model_commit (DeeTransactionModel *transaction);
In order to cancel a transaction one would simply unref the transaction.
FIXME: This approach would incur a lot of memory reallocation (all ops are essentially done twice). Perhaps the are clever workarounds...
MORE OPTIMIZED MESSAGE ROUTING
In the DeeModel protocol we use for Maverick the DBus signals RowsAdded/Removed/Changed does not pass the swarm name they apply to. This means that each swarm member must keep track of all swarm members and subscribe to their signals. Which means installing a new match rule for each swarm member and doing a lot of book keeping in the code.
If we instead mimicked what we already do in the DeePeer protocol we could pass the swarm name as the first argument of the signals. This way swarm members need only ever install one match rule ala:
interface='com.canonical.Dee.Model',type='signal',arg0='$swarmname'
This match rule would pick up all signals relevant to that swarm and nothing else.
PEER -2-PEER DBUS
In GDBus it's fairly easy to set up a peer-2-peer connection. This should save us the extra socket roundtrip we have when the DBus daemon is involved.
|
TRANSACTION BASED PROTOCOL
Currently the DeeModel DBus protocol has signals RowsAdded, RowsChanged, and RowsRemoved. This means that we can not support transactions in the wire protocol as well as many ops require two dbus messages. For example in the case of updating Unity search results we first fire off RowsRemoved to invalidate any non-matching rows, and then a RowsAdded with the new hits.
We need a protocol where this can be done in one message. I am thinking one signal like:
Commit(s swarm_name, aav row_data, au positions, ay change_code, (tt) seqnum_before_after)
Here row_data, positions, and seqnums are as in the current protocol, but the new arg 'change_code' is an enumeration with the values:
0: Add
1: Change
2: Remove
All the arrays in the Commit signal *must* have the same length, and like we also have currently in the protocol the positions vector is applied sequentially with each offset taking into account any previous row changes in the transaction affecting rows before it.
This would also mandate two new GInterfaces; DeeTransactionalModel and DeeTransactionModel that this builds upon. The transactional model could have one new method:
DeeTransactionModel dee_transactional_model_begin_transaction (DeeTransactionalModel *model);
And DeeTransactionModel is a proxy model (extending DeeProxyModel to help the impl) that buffers changes until someone calls:
void dee_transaction_model_commit (DeeTransactionModel *transaction);
In order to cancel a transaction one would simply unref the transaction.
FIXME: This approach would incur a lot of memory reallocation (all ops are essentially done twice). Perhaps the are clever workarounds...
MORE OPTIMIZED MESSAGE ROUTING
In the DeeModel protocol we use for Maverick the DBus signals RowsAdded/Removed/Changed does not pass the swarm name they apply to. This means that each swarm member must keep track of all swarm members and subscribe to their signals. Which means installing a new match rule for each swarm member and doing a lot of book keeping in the code.
If we instead mimicked what we already do in the DeePeer protocol we could pass the swarm name as the first argument of the signals. This way swarm members need only ever install one match rule ala:
interface='com.canonical.Dee.Model',type='signal',arg0='$swarmname'
This match rule would pick up all signals relevant to that swarm and nothing else.
PEER -2-PEER DBUS
In GDBus it's fairly easy to set up a peer-2-peer connection. This should save us the extra socket roundtrip we have when the DBus daemon is involved.
|
|
| 2010-12-15 15:32:10 |
Mikkel Kamstrup Erlandsen |
unity: status |
In Progress |
Fix Released |
|
| 2010-12-15 15:32:59 |
Mikkel Kamstrup Erlandsen |
dee: status |
In Progress |
Fix Released |
|
| 2011-01-18 12:43:13 |
Neil J. Patel |
unity: milestone |
3.4 |
3.2.12 |
|
| 2014-07-25 09:58:56 |
Marco Trevisan (Treviño) |
unity (Ubuntu): status |
New |
Fix Released |
|
