Re: [boost] [Locale] Preview of 3rd version

Subject: Re: [boost] [Locale] Preview of 3rd version
From: Lars Viklund (zao_at_[hidden])
Date: 2010-09-11 13:16:22

On Sat, Sep 11, 2010 at 04:59:23AM -0700, Artyom wrote:
> > 
> > Perhaps you could let users  supply a functor open_file(filename), and
> > they can choose to open the path  however they want, from whatever
> > source.  The default functor would use  what you currently have.  Would
> > this be prohibitively  difficult?
> >
> 
> Yes, it is doable.
> 
> However I don't think it is reasonable, I hadn't seen
> any localization system that does this. Putting dictionaries in file 
> system and using them is something common, also 
> it does not have any performance impacts as dictionaries
> should be loaded only once into the memory, unlike other game resources
> like video or images where fragmentation or access time may have effect.

There are many situations where it is unfeasible or even impossible to
write to or even read from the filesystem, nor have more than a small
set of files available, if any at all.

Consider these use cases:
* a plugin component for some existing application in the form of a
  DLL/so, where you then would store localization information inside
  your executable image;

* an ActiveX component for the web, where you have significantly
  restricted permissions and probably fall under the above case, but
  with more restrictions;

* a game or other application where your resources are baked into
  virtual filesystem images for efficiency and organizational purposes;

* a video game console, where you may have a filesystem to work with, or
  non-standard interfaces to work with one;

* any kind of application where you may retrieve the resources from
  external sources, like other parts of the filesystem or from a remote
  host.

The last case may sound a bit remote, but consider the case where you
have an application installed into a priviledged location like Program
Files or /usr. Assume that an end user wants to add new localizations
(which happens in real life) and he might not have write permissions
into the application directory. A solution to that is to have him put
his files in a directory he has permission to, typically in his home
directory, from which the localization can override lookups into.

> In any case, I would say, you can always re-implement your own 
> boost::locale::message_format
> facet to deal with such non-standard situation.

Judging by the name of that type and it's apparent purpose, it sounds
like quite a strange place to be hacking in file handling when it should
be properly extendable.

The counter-argument that you need directory information for traversal
sounds like something that should be easily accomodatable in a proper
extension point. As far as I can see to support your fallbacks, all you
need to have is the ability to query and enumerate entities in a
hierarchy and retrieve istreams to them.

For such an apparently rich and useful library, I find this restriction
rather strange.

-- 
Lars Viklund | zao_at_[hidden]