Questions about GossipContactManager

Hello,

I'm fixing telepathy backend to use the new API and contact manager.
Here are my problems:

1) Is gossip_protocol_find_contact() still useful ? Shouldn't we use
gossip_contact_manager_find() instead now ?

2) When gossip starts, gossip_protocol_new_contact() is called to create
all contacts saved in a xml file. That's useful for offline viewing logs
and others reasons... But should the backend keep those contacts even if
it's not connected ? Backend can't request avatar/alias/etc before
connecting. When disonnecting GossipJabber protocol it removes all
contacts from its hash table but contact manager don't, so the sate is
not coerent between offline before first connection and offline after
first connection. What should be done here ?

3) Using telepathy we can't know own-contact's ID before connecting
account. GossipContactManager gets own contact from the protocol even if
offline, is it a problem if it returns a GossipContact with NULL ID and
create a new GossipContact object (Previous one is finalized) with all
information once the account is connected ?

4) If jabber backend the own contact is created in jabber_setup() and
its ID is set to the account's "account" param which is OK, but if we
change the jid of the account and then connect it jid of the account and
the one of own contact won't be equal I guess ? Potential problem here I
think.

5) The contact manager should connect to "notify::name" on each
GossipContact object and store the file when a name change I think.

Xavier.

_______________________________________________
Gossip-dev mailing list
Gossip-dev@...
http://lists.imendio.com/mailman/listinfo/gossip-dev

[Martyn Russell-3]

Xavier Claessens wrote:
> Hello,

Hi,

> I'm fixing telepathy backend to use the new API and contact manager.
> Here are my problems:
>
> 1) Is gossip_protocol_find_contact() still useful ? Shouldn't we use
> gossip_contact_manager_find() instead now ?

Well, one finds contacts for a given protocol and the other finds ALL
contacts that we know about. So no I would say there is a good reason
for keeping them both.

> 2) When gossip starts, gossip_protocol_new_contact() is called to create
> all contacts saved in a xml file. That's useful for offline viewing logs
> and others reasons... But should the backend keep those contacts even if
> it's not connected ?

Yes, why not? If it doesn't the GossipContactManager would have to keep
them all and the backend would have to query libgossip about contacts. I
think that is the wrong way round and shouldn't do that.

> Backend can't request avatar/alias/etc before
> connecting. When disonnecting GossipJabber protocol it removes all
> contacts from its hash table but contact manager don't, so the sate is
> not coerent between offline before first connection and offline after
> first connection. What should be done here ?

Then that is a bug. The backend shouldn't really remove the contacts
from the hash table. We need to check this to see what implications it
will have in the Jabber backend.

If this it not really plausible in the Jabber backend OR the Telepathy
backend, perhaps the GossipContactManager should keep the contacts and
be the place to create them too - allowing sync with the backend when
they connect? Either way, contacts should really only be created in one
place.

> 3) Using telepathy we can't know own-contact's ID before connecting
> account. GossipContactManager gets own contact from the protocol even if
> offline, is it a problem if it returns a GossipContact with NULL ID

Yes, I can imagine that would be a problem in some places.

> and
> create a new GossipContact object (Previous one is finalized) with all
> information once the account is connected ?

Apart from protocols where you don't have an ID at any point, which
might be problematic, I can't see why you can't create a contact object
before connecting.

> 4) If jabber backend the own contact is created in jabber_setup() and
> its ID is set to the account's "account" param which is OK, but if we
> change the jid of the account and then connect it jid of the account and
> the one of own contact won't be equal I guess ? Potential problem here I
> think.

That's a good point. I think we should put something in place here to
make sure they are kept in step.

> 5) The contact manager should connect to "notify::name" on each
> GossipContact object and store the file when a name change I think.

Yes, we should be doing this.

--
Regards,
Martyn
_______________________________________________
Gossip-dev mailing list
Gossip-dev@...
http://lists.imendio.com/mailman/listinfo/gossip-dev

On lun, 2007-02-19 at 11:31 +0000, Martyn Russell wrote:

> Xavier Claessens wrote:
> > Hello,
>
> Hi,
>
> > I'm fixing telepathy backend to use the new API and contact manager.
> > Here are my problems:
> >
> > 1) Is gossip_protocol_find_contact() still useful ? Shouldn't we use
> > gossip_contact_manager_find() instead now ?
>
> Well, one finds contacts for a given protocol and the other finds ALL
> contacts that we know about. So no I would say there is a good reason
> for keeping them both.

Hum... gossip_contact_manager_find() search for a given GossipAccount,
so I would say it's the same than searching in protocol.

> > 2) When gossip starts, gossip_protocol_new_contact() is called to create
> > all contacts saved in a xml file. That's useful for offline viewing logs
> > and others reasons... But should the backend keep those contacts even if
> > it's not connected ?
>
> Yes, why not? If it doesn't the GossipContactManager would have to keep
> them all and the backend would have to query libgossip about contacts. I
> think that is the wrong way round and shouldn't do that.

Ok, right.

> > 3) Using telepathy we can't know own-contact's ID before connecting
> > account. GossipContactManager gets own contact from the protocol even if
> > offline, is it a problem if it returns a GossipContact with NULL ID
>
> Yes, I can imagine that would be a problem in some places.
>
> > and
> > create a new GossipContact object (Previous one is finalized) with all
> > information once the account is connected ?
>
> Apart from protocols where you don't have an ID at any point, which
> might be problematic, I can't see why you can't create a contact object
> before connecting.

Every protocol has an ID or some kind of unique string for the own
contact, but it's known only after connecting. I can create the contact
object but it won't have an id before the account is connected.

Xavier.


_______________________________________________
Gossip-dev mailing list
Gossip-dev@...
http://lists.imendio.com/mailman/listinfo/gossip-dev

[Martyn Russell-3]

Xavier Claessens wrote:

> On lun, 2007-02-19 at 11:31 +0000, Martyn Russell wrote:
>> Xavier Claessens wrote:
>>> Hello,
>> Hi,
>>
>>> I'm fixing telepathy backend to use the new API and contact manager.
>>> Here are my problems:
>>>
>>> 1) Is gossip_protocol_find_contact() still useful ? Shouldn't we use
>>> gossip_contact_manager_find() instead now ?
>> Well, one finds contacts for a given protocol and the other finds ALL
>> contacts that we know about. So no I would say there is a good reason
>> for keeping them both.
>
> Hum... gossip_contact_manager_find() search for a given GossipAccount,
> so I would say it's the same than searching in protocol.

Ah yea, of course good point. Perhaps this should just be internal for
the time being then. This way, if we change our minds and have contacts
created from the contact manager, then we can make it public.

>> Apart from protocols where you don't have an ID at any point, which
>> might be problematic, I can't see why you can't create a contact object
>> before connecting.
>
> Every protocol has an ID or some kind of unique string for the own
> contact, but it's known only after connecting. I can create the contact
> object but it won't have an id before the account is connected.

When you say ID do you mean an "id" parameter? i.e. are you talking
about the unique identifier for that contact which is given to you by
Telepathy - not actually an id that is relevant outside Telepathy?

If so, then setting that id after you have connected should be fine.

--
Regards,
Martyn
_______________________________________________
Gossip-dev mailing list
Gossip-dev@...
http://lists.imendio.com/mailman/listinfo/gossip-dev