> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On Behalf Of
> Krzeminski, Damian (BL60:9D30)
> Sent: Tuesday, July 28, 2009 5:15 PM
> To: [email protected]
> Subject: [sipX-dev] merging sipXconfig openfire plug-in and
> supporting code
>
> 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).
>
> 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.
>
I think that this is a very good point and I want to highlight that user
account creation/modification/removal is only one aspect of that
sipXconfig will have to push over to openfire (user groups are likely
next) so we probably need a generic solution. It is very important that
openfire-affecting configuration changes done via sipXconfig can succeed
even when openfire is down and be applied when it comes back up. Would
it make sense for sipXconfig to keep a journal of every configuration
operation that needs to be performed on openfire and have a background
task that reads the entries from the journal and executes them in order.
All that sipXconfig does is add new config tasks to the journal and they
get performed in the background when openfire is up.
>
> 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.
>
> 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-60
05-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/
