2:34 a.m.
Hi Folks,
In terms of the PIM manager API, specifically:
"void SetPeer(string uid, dict properties)
Adds or modifies a peer. Modifying a peer does *not* affect
any contact data which might be cached for it.
"
And a peer itself characterised as a combination of [protocol, transport, address,
database, logdir, maxsessions]
I wonder if one modifies some of these keys should the behaviour in fact *affect* any
contact data which might be cached.
For instance, if we change the BT address for a previously PBAP synchronised phone, and we
then come and change the BT address to something different for that unique uid, should the
contact data not be invalidated?
Generally, should some properties of a peer be immutable?
Perhaps I'm miss interpreting the API description?
Warm Regards
Tom.
--------------------------------------------------------------
Intel Shannon Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263
Business address: Dromore House, East Park, Shannon, Co. Clare
This e-mail and any attachments may contain confidential material for the sole use of the
intended recipient(s). Any review or distribution by others is strictly prohibited. If you
are not the intended recipient, please contact the sender and delete all copies.
3:06 a.m.
On Thu, 2013-02-07 at 15:34 +0000, Counihan, Tom wrote:
Hi Folks,
In terms of the PIM manager API, specifically:
"void SetPeer(string uid, dict properties)
Adds or modifies a peer. Modifying a peer does *not* affect
any contact data which might be cached for it.
"
And a peer itself characterised as a combination of [protocol,
transport, address, database, logdir, maxsessions]
I wonder if one modifies some of these keys should the behaviour in
fact *affect* any contact data which might be cached.
For instance, if we change the BT address for a previously PBAP
synchronised phone, and we then come and change the BT address to
something different for that unique uid, should the contact data not
be invalidated?
At the level where peers are configured it is hard to determine which
property changes will invalidate data and whether that is the intended
behavior. Basically this would have to be defined for the specific
implementation and then hard-coded there.
For example, for the BT address, one could think of a situation where a
user has "My Phone" as peer and then replaces his phone. In this case he
probably has also migrated his data from the old to the new phone and
the cache is still valid.
I think if the user of the API makes changes where he wants the cache to
be removed, he should remove the peer first. That'll remove the data. A
dedicated
ClearCache(string uid)
method could also be added.
Generally, should some properties of a peer be immutable?
Perhaps I'm miss interpreting the API description?
No, your interpretation is spot on. The question is which behavior of
the method is desirable.
--
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.
1:16 a.m.
-----Original Message-----
From: Patrick Ohly [mailto:patrick.ohly@intel.com]
Sent: Thursday, February 07, 2013 4:06 PM
To: Counihan, Tom
Cc: syncevolution(a)syncevolution.org
Subject: Re: [SyncEvolution] SetPeer behaviour.
On Thu, 2013-02-07 at 15:34 +0000, Counihan, Tom wrote:
> Hi Folks,
>
> In terms of the PIM manager API, specifically:
>
> "void SetPeer(string uid, dict properties)
>
> Adds or modifies a peer. Modifying a peer does *not* affect
> any contact data which might be cached for it.
> "
> And a peer itself characterised as a combination of [protocol,
> transport, address, database, logdir, maxsessions]
>
> I wonder if one modifies some of these keys should the behaviour in
> fact *affect* any contact data which might be cached.
> For instance, if we change the BT address for a previously PBAP
> synchronised phone, and we then come and change the BT address to
> something different for that unique uid, should the contact data not
> be invalidated?
At the level where peers are configured it is hard to determine which
property changes will invalidate data and whether that is the intended
behavior. Basically this would have to be defined for the specific
implementation and then hard-coded there.
For example, for the BT address, one could think of a situation where a user
has "My Phone" as peer and then replaces his phone. In this case he
probably has also migrated his data from the old to the new phone and the
cache is still valid.
I think if the user of the API makes changes where he wants the cache to be
removed, he should remove the peer first. That'll remove the data. A
dedicated
ClearCache(string uid)
method could also be added.
> Generally, should some properties of a peer be immutable?
> Perhaps I'm miss interpreting the API description?
No, your interpretation is spot on. The question is which behavior of the
method is desirable.
What is confusing me, looking at this from the Application perspective. I have one API
that does both an Add new peer and modify an existing one.
The key open this is, is it possible (in corner cases where App looses its brain) that an
add new peer is infact a modify existing peer, and how would the application know?
If the peer exists, but an application looses sight of that, then it would not know to
clear the cache.
And does it become more challenging if we have multiple clients - what if both 'add a
peer' with unfortunately the same peer id and different parameters for proto,
transport.... Could the first in ultimately end up with a peer configuration that is
different from what it envisioned?
A suggestion if the above make some logic. If one removed the concept entirely of being
able to 'modify' a peer, it may make things simpler.
SetPeer checks for uniqueness of uid, returns error if that peer already exists.
Am I on to something here, or am I the on who's lost his brain :-)
Tom.
--------------------------------------------------------------
Intel Shannon Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263
Business address: Dromore House, East Park, Shannon, Co. Clare
This e-mail and any attachments may contain confidential material for the sole use of the
intended recipient(s). Any review or distribution by others is strictly prohibited. If you
are not the intended recipient, please contact the sender and delete all copies.
1:31 a.m.
On Mon, 2013-02-11 at 14:16 +0000, Counihan, Tom wrote:
What is confusing me, looking at this from the Application
perspective. I have one API that does both an Add new peer and modify
an existing one.
The key open this is, is it possible (in corner cases where App looses
its brain) that an add new peer is infact a modify existing peer, and
how would the application know?
It has to check first and rely on no-one making changes concurrently.
If the peer exists, but an application looses sight of that, then it
would not know to clear the cache.
I don't think the middleware should be designed to work around bugs in
the application if it leads to a more complex API, because the
complexity itself breeds bugs.
And does it become more challenging if we have multiple clients -
what
if both 'add a peer' with unfortunately the same peer id and different
parameters for proto, transport.... Could the first in ultimately end
up with a peer configuration that is different from what it
envisioned?
The API is not meant to be used by multiple clients. If we allow that,
then we need to introduce a concept of locking the configuration.
SyncEvolution underneath has it, and it makes writing clients
considerably harder. Therefore I did not include that concept again when
designing the PIM Manager API.
A suggestion if the above make some logic. If one removed the
concept
entirely of being able to 'modify' a peer, it may make things simpler.
SetPeer checks for uniqueness of uid, returns error if that peer
already exists.
We can certainly do that. I just wonder whether we can be really sure
that an app will never want to make config changes.
We can defer the decision by renaming SetPeer to CreatePeer and adding
the uniqueness check. Then a ModifyPeer can be added later.
--
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.
1:54 a.m.
-----Original Message-----
From: Patrick Ohly [mailto:patrick.ohly@intel.com]
Sent: Monday, February 11, 2013 2:32 PM
To: Counihan, Tom
Cc: syncevolution(a)syncevolution.org
Subject: Re: [SyncEvolution] SetPeer behaviour.
On Mon, 2013-02-11 at 14:16 +0000, Counihan, Tom wrote:
> What is confusing me, looking at this from the Application
> perspective. I have one API that does both an Add new peer and modify
> an existing one.
>
> The key open this is, is it possible (in corner cases where App looses
> its brain) that an add new peer is infact a modify existing peer, and
> how would the application know?
It has to check first and rely on no-one making changes concurrently.
> If the peer exists, but an application looses sight of that, then it
> would not know to clear the cache.
I don't think the middleware should be designed to work around bugs in the
application if it leads to a more complex API, because the complexity itself
breeds bugs.
> And does it become more challenging if we have multiple clients - what
> if both 'add a peer' with unfortunately the same peer id and different
> parameters for proto, transport.... Could the first in ultimately end
> up with a peer configuration that is different from what it
> envisioned?
The API is not meant to be used by multiple clients. If we allow that, then we
need to introduce a concept of locking the configuration.
SyncEvolution underneath has it, and it makes writing clients considerably
harder. Therefore I did not include that concept again when designing the
PIM Manager API.
> A suggestion if the above make some logic. If one removed the concept
> entirely of being able to 'modify' a peer, it may make things simpler.
> SetPeer checks for uniqueness of uid, returns error if that peer
> already exists.
We can certainly do that. I just wonder whether we can be really sure that an
app will never want to make config changes.
I don't think we can every be 100% sure, but I would hazard a guess that if this
happens it happens very infrequently. Infrequently enough to suffer the minor heart ache
of removing and recreating the peer.
And thinking about the phone example earlier, we have no guarantee that the 'old'
phone is decommissioned or the new phone doesn't go through some offline refinement
before being reintroduced.
There are so many what-ifs, my leaning it to make it ultra simple and avoid the modify
until one has clear line of sight that it can be utilised effectively.
We can defer the decision by renaming SetPeer to CreatePeer and adding
the uniqueness check. Then a ModifyPeer can be added later.
That would be my leaning.
Warm Regards
Tom
--------------------------------------------------------------
Intel Shannon Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263
Business address: Dromore House, East Park, Shannon, Co. Clare
This e-mail and any attachments may contain confidential material for the sole use of the
intended recipient(s). Any review or distribution by others is strictly prohibited. If you
are not the intended recipient, please contact the sender and delete all copies.
2:02 a.m.
On Mon, 2013-02-11 at 14:54 +0000, Counihan, Tom wrote:
> > A suggestion if the above make some logic. If one removed
the concept
> > entirely of being able to 'modify' a peer, it may make things simpler.
> > SetPeer checks for uniqueness of uid, returns error if that peer
> > already exists.
>
> We can certainly do that. I just wonder whether we can be really sure that an
> app will never want to make config changes.
I don't think we can every be 100% sure, but I would hazard a guess that if this
happens it happens very infrequently. Infrequently enough to suffer the minor heart ache
of removing and recreating the peer.
And thinking about the phone example earlier, we have no guarantee that the 'old'
phone is decommissioned or the new phone doesn't go through some offline refinement
before being reintroduced.
There are so many what-ifs, my leaning it to make it ultra simple and avoid the modify
until one has clear line of sight that it can be utilised effectively.
>
> We can defer the decision by renaming SetPeer to CreatePeer and adding
> the uniqueness check. Then a ModifyPeer can be added later.
That would be my leaning.
Okay, deal. I'll make the change right away.
--
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.
3506
days inactive
3510
days old
syncevolution@synevolution.org
5 comments
2 participants
participants (2)
-
Counihan, Tom -
Patrick Ohly