[Kde-pim] Threaded ldap search class

[Szombathelyi György]

Sean Harmer írta:
> Hi,

>> The possible solutions I can imagine:
>> - Force the users of the class to use only one search thread. But It can
>> break too, when you mix LdapThreadSearch and other LdapOperations methods.
>> - Try to put only ldap_result (your waitForResult() func in LdapOperation) 
>> to the thread, and pray that this lonely function is reentrant.
> Hmm, I don't like relying on blind luck. In my experience someone will always 
> break it.
Yes, you're right!

> 
>> - Give up this great thing, and use the event loop again, but be smarter:
>> don't block till a message arrives, but poll (call waitForResult with 0
>> msec - but that can be slow, and CPU consuming), or block for a small
>> amount of time (e.g. 10 msecs).
> I think the safest option for now will be to use the event loop and block for 
> a short period of time as you suggest. This will at least make it *appear* 
> non-blocking with slow ldap connections.
> 
I'm currently porting KUser to use KLDAP instead of kio_ldap, during 
this I'll experiment with LdapSearch to block only for short periods. 
I've got a question about your waitForResult(): why does it need to have 
the QTime hack? Something breaks the waiting in ldap_result, so it 
returns before timeout?

> Maybe for KDE 4.x where x >= 1. I'll keep plugging away at it locally to get 
> the API straightened out - this shouldn't take long. When I have it in a 
> reasonable shape, I'll post it and then we can see if it works and how much 
> work may be required in libldap_r to make it reliable. It would be a shame to 
> let it die and it must be possible (given enough time and effort).
> 
Working on OpenLDAP is definitely a good thing, but it would be nice to 
make KDLAP work with other LDAP client libraries (I'll want to make it 
work win WLDAP32.dll in Windows somewhen...It's not hard, the API is the 
  same in 99%, just need to adapt the CMake files, but first I need to 
set up a Windows build system for KDE).
> I really need to get working on the ldapmodel again though. My thoughts for 
> this are to have a single class, LdapModel, derived from QAbstractItemModel 
> And then two convenience proxy models that filter it to display the 
> structural aspects of the ldap tree and the contents of a single ldapobject 
> in the hierarchy. I need to do some more thinking on whether this is a 
> sensible approach though.
> 
Sorry, I can't really help in this now, but you seems to be more 
experienced than me on this model-view thing, so just go ahead!
> Regards,
> 
> Sean

Bye,
György
_______________________________________________
kde-pim mailing list
kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
kde-pim home page at http://pim.kde.org/