> - the API doesn't explicits the client/server model chosen by
> the ST team, nor the way it manages/lists installed fonts.
>
> This means that if the client/server model doesn't provide
> reasonable benefits (or if it brings too many annoyances),
> it's still possible to change the implementation to more
> common things (like a user-side libraries).
This is very true. In fact, at this early point in the implementation,
while everything is coded to allow for client/server communication to be
dropped into place, the font server is loaded into the client process as
a shared library. We are still committed to splitting the server process
into it's own address space as we progress in the implementation of ST.
One of our design goals is to make the architecture scalable from a desktop
where the Xserver is the only client to a SunRay server where there may be
hundreds of Xservers and hundreds of other non-X clients, all using ST.
Obviously we won't be able to tell if we succeeded until we actually finish
the implementation.
> However what would happen if the ST Font Server crashes for one reason
> or another ?? Is there a way for the extension to re-connect to the
> server and have its state restored in a coherent state ?
Most of the state is kept in the ST Client Library - there would be some problems
in the current design, such as the CreateFont call which allows applications to
send down a font of their own. This is definitely something we'll need to include
in our design.
> However, a fix in XST of ST Client library will need an update of
> the code providing the XST extension. Any API addition or protocol
> change as well..
A fix to the ST Client Library should require simply replacing libST.so
on any system with dynamic linking. Only changes to the ST API or XST
protocol would require changes to the XST server extension. Since XST
is a non-invasive extension (it requires no changes to the server outside
of handling the new extension requests), it should be dynamically-loadable
on systems such as XFree86 and Xsun that support such things.
> I know that you're going to find me picky :o) However, this kind of code is
> present in both the client and server sources of ST, which means that:
>
> - the FontServer is susceptible of simple crashes in the case of
> memory exhaustion. Unlikely but still possible, and with dire
> consequences..
>
> - the Client library is also susceptible to such crashes. In the
> event where you'd like to use it within an X Server extension, this
> could mean that the X Server would crash under the same conditions
We definitely plan to improve the robustness of the ST & XST code as it
evolves. There are many places where error checking is currently done by
assert that will have to be replaced with non-fatal error checks, as
killing the Xserver when an assertion fails is not acceptable error handling.
We will take your other comments into consideration - feedback like this is
why we opened up the architecture to public review this early in the process.
We want to make sure we end up with a usable end product and wanted to allow
changes to the design before too much of it was set in stone.
-Alan Coopersmith- [EMAIL PROTECTED]
Sun Microsystems, Inc. - Software Systems Group
Cust. Advocacy & Tech Services: X11 Engineering
_______________________________________________
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts
