[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kopete-devel
Subject:    Re: [Kopete-devel] Identity API Questions
From:       Martijn Klingens <klingens () kde ! org>
Date:       2003-02-27 19:14:55
[Download RAW message or body]

On Thursday 27 February 2003 05:40, Jason Keirstead wrote:
> I have been looking over the identity API to start porting IRC and have a
> few questions

(Disclaimer: I haven't looked at the new API, so the below is more referring 
to my personal ideas and the way things worked until now. Apologies if I'm 
missing the point occasionally :)

> 	/**
> 	 * return the unique id of this identity which is the login
> 	 */
> 	QString identityId();
>
> I imagine this is supposed to be like my ICQ number, or MSN email
> address... anyway, I just want to make sure that it is known that this ID
> will not be unique.. if it is depended on that this be unique, there will
> be a problem.

That's the same now with contactId() (myself->contactId() currently). It's 
supposed to be unique per protocol, not globally.

From your description I understand that even 'per protocol uniqueness' is 
impossible to achieve with IRC and Jabber. That would be a major setback, and 
maybe even technically inacceptable given our API, since we can't uniquely 
identify a given object other than by pointer anymore. (And scripting like 
dcop or perl needs an ascii-representation, so just using pointers 
unfortunately can't cut it. Not as far as I can see at least.)

The only two solutions that I see is that for both IRC and Jabber the 
combination server + id is used as identityId (and is thus unique), or that a 
field server() is added (which defaults to QString::null for most protocols) 
and that server() + identityId() is used as lookup key and made unique.

> this ID would only be unique on the single server protocols
> like ICQ and MSN. Or am I reading this wrong?

No, you're not. Until now it was possible to do it like this, so I think 
nobody realized that it wasn't scalable :(

> 	/**
> 	 * Get the password for this identity. If no password are stored, it will
> pop up a * error=true mean that the last password typed was wrong and
> re-ask it * return the password or QString::null if the user has canceled
> 	 */
> 	QString getPassword(bool error=false);

Should be 'password()', not 'getPassword()'. Prefixing get is highly uncommon 
in Qt/KDE and is generally frowned upon when it's used to access properties 
(like here).

> 	/*
> 	 * Set the password for this identity. A null identity mean that the
> password is not remember * Should be called only by EditIdentityWidget
> 	 */
> 	void setPassword(const QString &pass = QString::null);
>
> According to this, you cannot have empty passwords....

Not true. That is, if the code is written correctly ;-)

QString::null != "". Compare isEmpty() with isNull(), so the two can still be 
distinguished.

Obviously it's possible that the code at the moment breaks on this corner case 
(no idea), but it can be fixed without changing the API.

> Also, i see in the identity manager there are two functions, connectAll and
> disconnectAll, I would suggest we also have a connectAllProtocol(
> KopeteProtocol* ) and disconnectAllProtocol( KopeteProtocol *) so that you
> can easily disconnect all identities of a specific protocol at once.

Good idea. Seconded.

-- 
Martijn

_______________________________________________
Kopete-devel mailing list
Kopete-devel@mail.kde.org
http://mail.kde.org/mailman/listinfo/kopete-devel
[prev in list] [next in list] [prev in thread] [next in thread]