On Wed, Jul 29, 2009 at 8:00 AM, Damian Krzeminski<[email protected]> wrote:
> 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.
>
Should the openfire plugin then take a list of user accounts and do
the setup for these accounts rather than the current scheme (which is
one at a time). This does not address the problem of openfire not
running at the time of the setup. SIpxConfig then does only one xml
rpc API and just ships an update list. I can easily add this method
if thats the way to go.
> 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/
>
--
M. Ranganathan
_______________________________________________
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/
