As I was writing another mail asking for some info on the layout of the configuration schema this mail came in :).
I'm trying to get my hands on the config data to try to make it portable between systems (mostly user and phone config). sipXconfig is using a framework called Hibernate (https://www.hibernate.org/) to persist in core objects into SQL. There are a ton of mapping files that map classes in java (accessed via java's introspection facilities) into tables and columns in the SIPXCONFIG database. Any understanding of the SQL representation will come from understanding the various live classes touched by the jetty webserver and how they are mapped to the tables. No specific recommendations, just what I've discovered in my quest to understand the SIPXCONFIG schema so far. -Eric On Jan 18, 2010, at 11:09 AM, Marden P. Marshall wrote: > I have been looking into ways in which to improve the dissemination of > application configuration data. Specifically to make the configuration data > available to the application in realtime and in a granular form, as opposed > to the current bulk delivery mechanism, i.e. configuration files. There were > attempts in the past to do this, utilizing proprietary provisioning protocols > running over XML-RPC, but the results fell short of the intended goals. So > now I am looking at a simpler and more direct approach, namely, to have the > applications access the configuration data directly, via the configuration > database. > > In order to achieve the objective of realtime and granular dissemination, the > database would utilize the postgreSQL Listen / Notify mechanism, in > conjunction with table modification triggers. The application would then > subscribe, i.e. Listen, for relevant database tables modification > notifications. In response to the received notifications, the application > would then query the database directly for the updated configuration. No > more waiting for configuration files to be created / replicated and no more > application restarts. > > How the application accesses the database records would be based upon the > specific needs of the application and the complexity of the associated > configuration data, but would most likely be through simple SQL queries, O/R > mapping middleware or some combination of both. For mission critical > applications, a local configuration cache, in the form of a properties or XML > file, could be maintained. This would allow the application to start up in > the absence of database connectivity, an approach that is already employed by > some applications. > > Any thoughts? > > > -Mardy > > _______________________________________________ > 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/
