On Jan 18, 2010, at 3:21 PM, Scott Lawrence wrote: > On Mon, 2010-01-18 at 13:19 -0500, Dale Worley wrote: >> On Mon, 2010-01-18 at 12:09 -0500, Marden P. Marshall wrote: >>> 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. >> >> It looks like this scheme requires that the application understand the >> database schema for the data it is interested in. > > I hadn't thought about that part, but that's an excellent observation. > Direct access to the database means creating a coupling between the > implementation of every service using this scheme and the database > schema, which makes schema changes more difficult and more disruptive of > development. >
Our configuration database schemes are very simple and in some cases nothing more than "flat file" layouts. And once they are initially defined, they change little over time. There are also many tools at the disposal of the developer to help with automating the process of mapping a database scheme to an object representation. And remember that all of this is taking the place of the development of another "scheme" that now has to be kept in-sync between Config Server development and application development, the config file. -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/
