Hi Jan, Here are my comments.
- You propose to a module called G11nInstall. The name makes it sound like it is only useful for install related components. Looking at the list of functionalities, it is very general, it can actually be use by any application that needs information about locales/language. You might consider to use a different name. - The proposal indicates that the module will provide C interfaces. Considering that most of the known customers to the G11nInstall module will not be using C, it would make more sense to provide a CLI interface to access the functionality provided by the G11nInstall module. I see that you have added a "test driver" interface to the proposal as suggested by Jan Damborsky, which is a good starting point. Please consider calling it a command line interface, not a test driver. When I see "test driver", I assume it as an unstable private interface used by testing, not for general use. Also, please make sure that the command line interface provides exactly the same functionality as the C interfaces. - In the examples of module consumers list, you mentioned the transfer module. I don't think that should be in this list. The transfer module will not be calling the G11nInstall module APIs directly. Some callers of the transfer module, eg: AI, DC or liborchestrator will call the G11nInstall APIs, figure out what languages/locales are needed, and then, pass that information into the transfer module. - In the example of module consumers list, please add Distribution Constructor (DC) as one of the consumers. DC will use the API to get list of packages needed to support a particular language/locale in the image. - From what I understand, requirements item 3-4 can't be implemented unless the needed functionality is available from IPS. Those are the functionality needed by the AI and DC project. Please indicate on the requirement section on what can be implemented immediately, and what can not, and what's the estimated time frame and dependencies. That way, different projects can plan accordingly. - For now, since you are porting orchestrator's locale.c program to the new API, it makes sense to provide the G11nInstall module as a C library. In the future, most of the items in the requirements list will be implemented using IPS calls, and that's in Python. Does it make sense to still have the G11nInstall module as a C library? Thanks, --Karen Jan Trejbal wrote: > Hello Caiman team. > I would like to propose a new module which provides information about > languages and locales. > It's actually not a brand new module. My plan is to take orchestrator > locale.c component, remove unused code, add some new functionality, and > separate it out into a new stand-alone shared library. > > I believe various installer appls (e.g. gui-install, AI) as well as > other system appls (e.g. post-install mngmt of language bits) would > benefit from proposed library. > > See more details at following document: > http://wikis.sun.com/download/attachments/45908778/g11ninstall_mod_proposal.pdf > > Can you please consider my proposal and review it? > Thank you, > Jan > > > > _______________________________________________ > caiman-discuss mailing list > caiman-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/caiman-discuss >
