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.
>
> 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.
>
> 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/
>
--
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/
