On Thu, 2009-12-03 at 13:44 +0900, Fuyuki Hasegawa - Sun Microsystems wrote: > Thank you for the review, Sebastien. > > Sebastien Roy wrote: > > On Wed, 2009-11-25 at 23:47 -0800, Fuyuki Hasegawa wrote: > >> The list of supported layout comes from xkeyaboard-config > >> rule data (xkeyboard-config - rules/xorg.xml). The iBus engine has > >> this layout list and the actual symbol data (xkeyboard-config - > >> symbols/*) > >> for each layout as iBus engine private data in its own format so > >> that > >> iBus engine does not depend on xkeyboard-condfig data at runtime. > > > > You should have an imported interfaces table where you list exactly > > which xkeyboard-config interfaces you depend on. > > Build time dependencies are: > /usr/X11/share/X11/xkb/symbols > /usr/X11/share/X11/xkb/rules > > I've added the following in the material. > > Imported Interfaces > > INTERFACE NAME STABILITY NOTE > > ----------------------------------------------------------------------- > /usr/X11/share/X11/xkb/* Uncommited XKB definition files
Okay, and these are exported as Uncommitted by PSARC 2009/440. This looks fine. > > > Are those safe to use? > > OpenSolaris Xorg server depends on these data, so we assume they're safe > to use. Indeed. > > > > >> INTERFACE STABILITIES > >> > >> All of components for this engine are Projectt Private. > >> > >> INTERFACE NAME STABILITY NOTE > >> > >> ----------------------------------------------------------------------- > >> /usr/share/ibus-xkbc Private iBus engine > >> implementation > >> in platform neutral way > >> (written with Python) > >> /usr/share/ibus/component Private engine specification file > >> /xkbc.xml > >> /usr/lib/ibus/ibus-engine-xkbc Private engine invocation script > >> /usr/lib/ibus/ibus-setup-xkbc Private engine specific > >> configuration > >> invocation script > > > > There has to be some Public interface provided by this project, > > otherwise the user would not be able to select this keyboard layout > > engine in the GUI, and then would not be able to depend on individual > > layouts offered by the engine. > > The last three are the files for the GUI. They're imported by the GUI, but I'm asking about interfaces that are used by the user. There has to be something that the user depends on as an interface. How are other features that are solely enabled and controlled through a GUI handled (ask folks on LSARC who have probably dealt with interface stabilities for such features)? > It seems fine to dedine them as Volatile. > However, we have defined them as Private in PSARC/2009/499 iBus integration. Some level of Private is fine for these, as the files themselves are do not constitute a Public interface. On a related note, which level of "Private" do you actually mean here? > > /usr/share/ibus/ Private ibus components registry > components/* like ibus-gconf, ibus-ui-gtk > and IMEs > /usr/lib/ibus/ Private IME setup launcher > > Should I update this case and PSARC/2009/499? No, but please do clarify what you mean by "Private" by specifying an existing stability level from the interface taxonomy. -Seb
