M. Ranganathan wrote:
> On Tue, Jul 28, 2009 at 5:15 PM, Damian Krzeminski<[email protected]> wrote:
>> I spent about 2 days rebasing/merging and for minor clean-ups.
>> I am afraid it still need some work before I can take it in the mainline.
>>
>> IM account creation
>> -------------------
>>
>> The current implementation talks to OpenFire (XML/RPC) when User objects
>> are saved or deleted. Unfortunately if you happen not to use OpenFire you
>> cannot save the user with IM ID (you try to save it and exception gets
>> thrown informing you that plug-in cannot talk to the server).
>>
>> Even if were to fix that, RPC calls from UI threads are not a good thing.
>> In case of any communication problems admins will be stack waiting for
>> connection to timeout. And even if it's not a UI thread saving user is kind
>> of time critical (think about importing users).
>
>
> SipXconfig could either generate an XML file with ALL the openfire
> users which could be considerable in number. This file can be
> replicated and later be read and the database updated as part of sipx
> openfire initialization. Or sipxconfig can directly update the pgsql
> database for openfire. However, the openfire database may not be
> co-resident with sipxconfig and hence network timeouts etc would come
> into play anyway. Not sure how to avoid that. I can go ahead and add
> database tasks for user creation an udpate if this is the way to go.
>
> Perhaps one can batch the operation - i.e. set up the necessary pgsql
> commands and run these asyncrhonously.
>
Just to be clear: I am not advocating that we drop XML/RPC. I am just
saying that sipXconfig has to become much smarter in how and when it is
calling the methods to create and delete OpenFire accounts.
What needs to happen is that sipXconfig keep the list of OpenFire users
synchronized with the list of sipXconfig users. The current implementation
works only if (1) we don't add remove users in bulk (2) OpenFire is
installed and working.
I was trying to outline a more robust approach above. But quite frankly
even a brute force solution with sipXconfig getting the list of IDs and
then removing the once that were removed and adding the once that were
added since last sync would be better than what is implemented now.
The idea with generating the file is of course extremely easy to implement
on sipXconfig side. But it's just pushing the problem to some other part of
that system: there has to be some code that can effectively reconcile 2
lists of the accounts.
Writing directly to OpenFire DB is for many reasons out of the question.
>
>
>> It would be much better if sipXconfig/openfire plugin worked in the
>> background creating/removing and changing IM accounts whenever something
>> changes in user data. It would be more in line with how configuring other
>> entities (phones or gateways work): sipXconfig saves configuration and then
>> reconfigures other entities to match. Of course in that setup we cannot
>> use hacks such as "savedImId" any more.
>>
>> I noticed that adding new Openfire account takes 3 - 4 RPC calls. It's
>> absolutely not critical but if sipXconfig is the primary client of that API
>> maybe we could make it more convenient.
>
>
>
>
>
>
>
>>
>> Saving users
>> ------------
>>
>> EditUser code seem to delete and recreate voicemail mailbox every time the
>> user is saved. It used to do that only when username changed but that
>> safeguard has been removed. I did not try to fix it since if IM account
>> creation happens in the background we probably just restore the original
>> code.
>>
>>
>> RLS generation
>> --------------
>>
>> A new resource list is generated to allow observing the state of all users
>> with IM accounts. That list has an ID "watcher": sooner or later someone is
>> going to create user "watcher" - maybe it would be better to use some kind
>> of special id from ~~namespace.
>
>
> A new name has been defined in the ~~ namespace. I understand that
> sipxconfig will be creating the special user and assigning
> credentials.
>
Super.
>> RLS generation is triggered from UI - that was a barely acceptable hack
>> when we used it for speed dial: especially since we only generated it when
>> username was changed. But we cannot afford to generate it unconditionally
>> every time user is saved ("importing users" use case again).
>>
>>
>> The rebased patch is here:
>> http://track.sipfoundry.org/secure/attachment/20528/0001-XX-6005-Support-for-managing-instant-messaging-serve.patch
>>
>>
>> _______________________________________________
>> sipx-dev mailing list [email protected]
>> List Archive: http://list.sipfoundry.org/archive/sipx-dev
>> Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
>> sipXecs IP PBX -- http://www.sipfoundry.org/
>>
>
>
>
_______________________________________________
sipx-dev mailing list [email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
sipXecs IP PBX -- http://www.sipfoundry.org/
