On Thu, 2009-10-01 at 19:47 +0900, Fuyuki Hasegawa - Sun Microsystems
wrote:
> Sebastien Roy wrote:
> > On Thu, 2009-09-17 at 03:54 -0700, Fuyuki Hasegawa wrote:
> >> Integrating ibus does not mean to obsolete iiimf or scim, but we
> >> would
> >> put them in maintenance state.
> >
> > What is "maintenance state"? If you mean that they will remain
> > supported but that ibus is the preferred method, then making them
> > "Obsolete" in the ARC sense would seem like the right thing to do. Is
> > that what you intend? See
> > http://www.opensolaris.org/os/community/arc/policies/interface-taxonomy/.
>
> The "maintenance state" means that we will stop feature work
> and unlikely to fix low priority bugs.
> iiimf is still default IM for OpenSolaris 2010.02.
> It seems we should change iiimf or scim interfaces to Obsolete
> when we switch default IM to ibus for Solaris Next.
I see, that works for me.
> >> 4.1.2 Switching between iBus, SCIM and IIIMF
> >> iBus services are started by gnome-session(1). User could
> >> simply enable
> >> or disable the service via gnome-session-properties(1). With
> >> the help of
> >> startup scripts shipped with iiimf and scim, user could set
> >> GTK_IM_MODULE
> >> environment variable in $HOME/.profile to select iBus, IIIMF or
> >> SCIM.
> >
> > Is the GTK_IM_MODULE variable an interface exported by this case, or was
> > it part of a previous case?
>
> GTK_IM_MODULE variable comes from GNOME itself.
> It's mentioned in gtk-query-immodules-2.0(1) manpage.
> I looked at GNOME 2.14 ARC materials in /shared/sac/LSARC/2006/202/,
> but couldn't find out the interface taxonomy.
Okay, that's fine.
> >
> >> 4.5. Interfaces:
> >>
> >> INTERFACE NAME STABILITY NOTE
> >>
> >> -----------------------------------------------------------------------
> >> /usr/bin/ibus-daemon Uncommitted message bus daemon
> >> /usr/bin/ibus-setup Uncommitted setup launcher
> >> /usr/libexec/ibus-x11 Uncommitted ibus XIM fontend/agend
> >>
> >> /usr/libexec/ibus-gconf Uncommitted config backend by
> >> gconf-python
> >> /usr/libexec/ibus-ui-gtk Uncommitted panel GUI by pygtk
> >>
> >> /usr/lib/libibus.so Uncommitted ibus C binding SDK library
> >> /usr/include/ibus-1.0/* Uncommitted ibus C binding header files
> >>
> >> /usr/share/gtk-doc/html/ Uncommitted ibus developor documents
> >> ibus/*
> >>
> >> /usr/lib/python2.6/ Uncommitted ibus Python binding
> >> site-packages/ibus/*
> >>
> >> /usr/lib/gtk-2.0/2.10.0/ Uncommitted ibus gtk-im-module
> >> immodules/im-ibus*.so
> >> /usr/lib/{amd64,sparcv9}/ Uncommitted 64bits version of ibus
> >> gtk-2.0/2.10.0/immodules/ gtk-im-module
> >> im-ibus*.so
> >>
> >> /usr/share/ibus/setup/* Uncommitted ibus-setup modules
> >> /usr/share/ibus/ui/gtk/* Uncommitted panel GUI by pygtk
> >>
> >> /usr/share/ibus/ Uncommitted ibus components registry
> >> components/* like ibus-gconf, ibus-ui-gtk
> >> and IMEs
> >>
> >> /usr/libexec/ Uncommitted IME launcher
> >> ibus-engine-<IME_NAME>
> >> /usr/libexec/ Uncommitted IME setup launcher
> >> ibus-setup-<IME_NAME>
> >> /usr/share/ibus-<IME_NAME> Uncommitted IME modules
> >> *IME_NAME is among [anthy, chewing, hangul, m17n, pinyin, table]
> >>
> >> /usr/share/ibus-table/* Uncommitted ibus-table engine and
> >> code-tables
> >
> > I suspect that many of the above are not actually interfaces at all, but
> > rather internal components of the implementation. No user or
> > application should be using most of these things directly, so
> > Uncommitted seems inappropriate. Can you clarify which interfaces you
> > expect users and applications to interact with directly and give those
> > appropriate stabilities. Everything else should probably be some kind
> > of private or not an interface at all.
>
> I see. It seems Project Private is more appropriate for all of them
> except the following.
>
> >> /usr/bin/ibus-daemon Uncommitted message bus daemon
> >> /usr/bin/ibus-setup Uncommitted setup launcher
>
> Since ibus is fairly new software and being actively developed/enhanced
> by the community. I think Volatile would be more appropriate for the
> two interfaces.
Do you expect users to call /usr/bin/ibus-daemon directly, or do you
only ever expect it to be started from private scripts indirectly by
gnome-session? If it's the former, then what you have is fine. If it's
the latter, then it probably belongs in /usr/lib along with the other
private executables, and it should be Project Private along with the
others. Otherwise, I agree with your assessment of the other
interfaces.
> >
> >> 4.12. Dependencies:
> >> We need python2.6 to be the default in OpenSolaris.
> >
> > What is the specific case dependency?
>
> I don't know what python2.6 API ibus depends on.
> We heard the python default will be changed from 2.4 to 2.6
> in near future, but don't know the actual target at this point.
According to PSARC/2009/043, you must not depend on the default version
in /usr/bin, but rather on a specific version
(e.g., /usr/bin/python2.6). That would relieve any dependency on a
particular version becoming the default, and would prevent breakage of
your feature if the default version changes and introduced
incompatibilities.
-Seb
