Hello Karen, thank you for reviewing my proposal and valuable suggestions. See my comments in-line.
Karen Tung wrote: > 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. You are correct, G11nInstall is a bit misleading for general locales/languages information module. What about I18nServices module? I18n = Internationalization which is more used term than G11n. > > - 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. Not sure if most of the consumers will be non-C, but I agree that command-line interface is better name than test driver. I updated the proposal document. > > - 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. Right, but then transfer module will need to know what packages or files should be installed for given list of languages/locales. That's why I think the transfer module will need to call the API. Maybe this is part of AI project, is it? If yes, then I should remove transfer module from the proposal. > > - 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. Good point, I included DC in the proposal. > > - 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. Ultimately, requirements #3 and #4 will be implemented using IPS meta data (language/locale tags) and filters, which is not possible currently. When certain IPS features will become available, we will change install management of language/locale bits. That's another, independent project. For the time being I plan to implement #3 and #4 functionality using simple static table of languages/locales and package names. I updated Implementation section of the proposal 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? You are right, in (distant) future implementation of the G11nInstall module may be completely overhauled. Currently, I am re-using most of the orchestrator's C code and defining the interface. In future we may either re-write in Python or provide Python wrappers for 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 >> >
