On Wed, 2008-05-14 at 18:33 +0200, Misha Vodsedalek wrote:
> The problem is that I don't really know and/or control what type of
> localization files will be required by a third party application. The
> mechanism I implemented is intentionally generic to allow effectively
> anything what might be required by third party applications to be installed.
> Some applications could use files that would better fit into /usr/lib
> (architecture dependent files) while other applications could use files that
> better fit into /usr/share (architecture independent files). Even worse -
> some applications could use a combination - and I believe that's the case of
> our third party application.
It sounds to me as though you are conflating two things that I consider
different:
* Localization
This is the process of adapting the system and
especially its human interfaces (including text strings,
voice prompts, dial plan templates, etc) to the
conventions appropriate to a particular deployment area.
* Functionality add-ons
This is the process of adding a new functional component
to the system. It might have new binaries, new
libraries, new configuration files, new plugins for
existing sipXecs components, etc.
It seems to me that Localization should be doable in a /usr/lib/sipxecs
directory (which could be created by sipXcommserverLib and owned by the
SIPXPBXUSER if it isn't already). Dropping a directory of stuff there
should enable sipXconfig to link the required bits into the other
directories.
The second item sounds more like what you're describing, and I think
that should be done with rpms just like we do with sipXecs compoenents.
We should not attempt to re-invent the functionality of rpms in some
other mechanism. (Actually, I'd argue that even Localization packages
should be rpms, but I'm willing to concede that that might raise the bar
to producing them higher than we want it to be right now)
--
Scott Lawrence tel:+1.781.229.0533;ext=162 or sip:[EMAIL PROTECTED]
sipXecs project coordinator - SIPfoundry http://www.sipfoundry.org/sipXecs
CTO, Voice Solutions - Bluesocket Inc. http://www.bluesocket.com/
http://www.pingtel.com/
_______________________________________________
sipx-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
