headers
Misha Vodsedalek | 14 May 16:32
Favicon

A good location for third party localization files

Even though the documentation for localization packages on the sipX Wiki 
does not mention it yet (quite intentionally), it is actually possible to 
include localization files for third party applications in localization 
packages.  My initial implementation (submitted in 3.9) places these third 
party files into /etc/sipxpbx/third_party.  When I found out that using this 
location is not optimal, it was too late to change it for the 3.9/3.10 
stream.

The main reason why /etc/sipxpbx should not be used for various "junk" such 
as third party files is simple - the entire directory structure gets 
included in snapshots and thus should contain only configuration files!  My 
personal guess is that not that many designers actually know this, because 
you can find variety of files in the directory structure. :-)

Sorry for the long introduction - now to the point.  I don't want to make 
the same mistake twice, so I am looking for some feedback with regard to the 
right location for third party localization files.  I am considering moving 
the third party directory to
    /var/sipxdata/third_party
Would that be okay or are there any gotchas related to the /var/sipxdata 
directory structure?  Would there be a better (or more appropriate) location 
for such files?

Please note that the requirement is that sipXconfig must be able to write 
into the base directory in which the directory third_party will be created 
(it's sipXconfig that actually installs the localization files).  So, the 
directory should be owned by sipxchange.

Cheers,
Misha
(Continue reading)

Permalink | Reply |
headers
Scott Lawrence | 14 May 17:28

Re: A good location for third party localization files


On Wed, 2008-05-14 at 16:34 +0200, Misha Vodsedalek wrote:
> Even though the documentation for localization packages on the sipX Wiki 
> does not mention it yet (quite intentionally), it is actually possible to 
> include localization files for third party applications in localization 
> packages.  My initial implementation (submitted in 3.9) places these third 
> party files into /etc/sipxpbx/third_party.  When I found out that using this 
> location is not optimal, it was too late to change it for the 3.9/3.10 
> stream.

We have tried (not always successfully) to use the Filesystem Hierarchy
Standard <http://www.pathname.com/fhs/pub/fhs-2.3.html> as a guide to
this sort of thing.

> The main reason why /etc/sipxpbx should not be used for various "junk" such 
> as third party files is simple - the entire directory structure gets 
> included in snapshots and thus should contain only configuration files!  My 
> personal guess is that not that many designers actually know this, because 
> you can find variety of files in the directory structure. :-)
> 
> Sorry for the long introduction - now to the point.  I don't want to make 
> the same mistake twice, so I am looking for some feedback with regard to the 
> right location for third party localization files.  I am considering moving 
> the third party directory to
>     /var/sipxdata/third_party
> Would that be okay or are there any gotchas related to the /var/sipxdata 
> directory structure? 

The FHS says:
(Continue reading)

Permalink | Reply |
headers
Misha Vodsedalek | 14 May 18:33
Favicon

Re: A good location for third party localization files

Scott, thanks for the input.  Comments below...

"Scott Lawrence" <slawrence <at> pingtel.com> wrote in message 
news:1210778900.3196.286.camel <at> scott.skrb.org...
> The FHS says:
>
>        /var contains variable data files. This includes spool
>        directories and files, administrative and logging data, and
>        transient and temporary files.
>
> that doesn't fit.

Well - the question really is what actually happens to the files after the 
installation.  The third party software we use (and for which I added this 
feature) actually makes a copy of files that match the language identifier 
in domain-config.  So, the files could be considered temporary... :-)

> I'd say the installation directory should be either
> /usr/lib/sipxecs/locale/≤locale_id>
> or
> /usr/share/sipxecs/locale/≤locale_id>
....
> So I think the distinction is whether or not the files are
> architecture-independent: if so, share, if not, lib.

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
(Continue reading)

Permalink | Reply |
headers
Scott Lawrence | 14 May 20:07

Re: A good location for third party localization files


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
(Continue reading)

Permalink | Reply |
headers
Misha Vodsedalek | 14 May 20:34
Favicon

Re: A good location for third party localization files

> 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)

Actually, the original design proposal was to use RPMs for localization 
packages.  There was some resistance to that idea because some Linux 
distributions do not support RPMs and due to the perceived complexity - I 
was asked to change the format to something simple what could be used on any 
Linux OS.  As a result, the initial implementation supports TAR files with 
RPM being mentioned as the next format to consider in a future release.

Misha
Permalink | Reply |

Gmane