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

List:       kopete-devel
Subject:    RE: [Kopete-devel] sms protocol problems
From:       Richard_Lärkäng <nouseforaname () home ! se>
Date:       2003-07-16 15:06:26
[Download RAW message or body]

Hi!

Thanks a lot for trying to fix it.

The sms-plugin was basically the first non-toy programming
thing I wrote, so the design is far from perfect, and
the port to accounts was basically done in a few hours,
mostly moving code from smsproject to smsaccount and
making it compile.

I don't have the time to look at the issues right now,
but I'll try to answer it soon, maybe tonight/tomorrow.

Feel free to rewrite whatever you think is needed if you
want to.

Richard

> 
> i had a spare few minutes so i had a look at the problems of 
> the sms plugin, 
> as i'd really like to see it functional in 0.7 (i reckon 
> on-demand sms could 
> be a killer feature of kopete; it's certainly damn useful for 
> me); the good 
> thing is that the bugs i found are really only symptoms of 
> one problem. the 
> bad news is that the problem appears to be quite a deep rooted design 
> shortcoming.
> 
> essentially, the editaccountwidget used to create new 
> accounts in the wizard 
> begins by creating an account with a null accountId. this is 
> problematic 
> since it cannot be properly hashed and appears to be the cause of the 
> symptoms i wrote before (crash in rmb to account status icon; 
> no item shows 
> up in account dialog).
> 
> in other protocols, the account creation is deferred until 
> the apply() method, 
> where the accountId is known and all is ok --- this appears to be the 
> "correct" way of the doing it.
> 
> unfortunately, due to the design of the sms protocol, this 
> cannot be deferred 
> until the apply function, since SMSService (a class to handle 
> the interfacing 
> to the actual services used to send messages) requires an 
> SMSAccount object 
> in its constructor.
> 
> an SMSService object is needed *before* the apply() method in 
> order to allow 
> population of the various service-specific parameters.
> 
> i can think of several solutions:
> 
> 1. refactor SMSService to not require an SMSAccount object in 
> the constructor: 
> the (afaict) best solution, though could be a lot of work.
> 
> 2. allow addition of an extra page to the wizard so the 
> account name and the 
> sms service details have to be provided strictly sequentially 
> and apart from 
> oneanother: if the current smsservice design is to be kept, 
> this is probably 
> the most obvious solution, however it really is a workaround, 
> and may require 
> api changes to the editaccountwizard system.
> 
> 3. delete/recreate accounts on the fly in the 
> editaccountwidget, as and when 
> the account's id is changed. inefficient, pretty horrible.
> 
> 4. introduce a "Set" button next to the account ID text box 
> and make the 
> button click create an SMSAccount; force an SMSAccount to be 
> created before 
> service specifics may be chosen: complete ui hack and usability-wise 
> horrible, however a bit better than #3, and it definately works ok.
> 
> comments/corrections/ideas?
> 
> i have a bit of free time in the next few days, so i may be 
> able to put a bit 
> of work into getting it ready for 0.7....
> 
> gav
> 
> - -- 
> Gav Wood <gav@kde.org>
> 
> codito ergo non satis bibivi
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.0 (GNU/Linux)
> 
> iD8DBQE/FTkm7nE5x1pIEBQRAqIIAJ9IsynLO6Bb2G8zgoPBCcAKEx7o6ACeJOM1
> SQtmYhGEivPobd86sFS2Nfo=
> =y9qP
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> Kopete-devel mailing list
> Kopete-devel@mail.kde.org 
> http://mail.kde.org/mailman/listinfo/kopete-> devel
> 
> 


_______________________________________________
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]