🚀 go-pugleaf

In article <4502@mit-vax.LCS.MIT.EDU: jim@expo.lcs.mit.edu (Jim Fulton) writes:
:>                                       However, certainly in the case
:> of X, I think that they have made an error in their way of implementing
:> the Toolkit libraries. 
:>
:> X causes the toolkit libraries to be linked in with the application
:> code. This causes large applications which are only portable between
:> X servers -- fair enough.
:
:X (i.e. the X Protocol) has nothing to do with whether or not a toolkit is
:linked into an application.

Yes, I recognized this and stated in the next paragraph that X did not
require you to do this, simply that this was the way it was being used.
I also recognize that X `The Protocol' is completely independant of
the particular implementation. However, I had hoped that the statement
about `implementing the Toolkit libraries' was clear enough in that
I was refering to the implementation not the protocol.

However, upon reflection, I think that `error in implementation' was
a poor choice of words. What I was trying to say was that the X
toolkit routines, being presented as linkable subroutines, were temping
many people to call them from directly within their client applications
and that, this may not be the best choice under my definition of
portability.

:                             Also, if one has shared libraries, even
:sophisticated applications aren't all that large. 

Unfortunately, even today, that if is a pretty big one! Yes, I know
that all systems will tend toward shared libraries eventually, but,
some of us are trying to use the X system today (both protocol and
implementations) in `older' environments.

:The X Toolkit was designed to take maximum advantage of the X Window System.
:People who want window-system independence, or who aren't running X, will
:probably want to choose another toolkit (such as Andrew, STDWIN, etc.) or
:design their own.  It all depends on what one's definition of "portability" is,
:or more importantly, on what the requirements of the situation are. 

Again, we agree. For the article I was using `the ability to move to 
other windowing systems with minimum effect on the application' as a
localized definition of `portability'.

:> So, why not add layers of protocols between the application,
:> something I will call the "agent" and the window manager?
:
:Ah, motherhood and apple pie!  This "agent" is often called a User Interface 
:Management Systems and is rapidly becoming one of the hotter topics for
:research and development.  Lots of opportunities for Cognitive Scientists,
:Graphic Artists, and even Software Engineers. :-)

I was not willing to use the term IUMs initially since that term was
rather over-used and abused in the Office Automation market about
5 years ago. I built IUMs for curses-based screens at that time,
but was never really satisfied with them since, in my opinion, they
never really hit to the center of the problem. (which I will outline
at the end of this)

:Providing a good foundation for building UIMS's was one of the design goals of
:the X Toolkit.

And in this, I think you have succeeded! The fact that I could implement
so much of Prism (my UIM environment) with it lends strong credence to
the statement. 

:                There are currently several commercially available UIMS's (e.g.
:X-Pression, Open Dialogue, XUI, New Wave, etc.) and I expect to see a flurry of
:new announcements over the next year. 

:							Jim Fulton
:							MIT X Consortium

Jim, somehow it appears that you have mistaken my comments to be an
attack of X (or the X toolkit at any rate). This was not my intention.
I am the Canadian X Software Repository moderator and support the X
system to its fullest. My comments were more a comment on the way in
which the X toolkit was being used by current implementors and how
their method of implementation required that their applications would
have to be substantially rewritten in order to move to another windowing
system. Good software is expensive to write once, let alone for each
type of bitmapped windowing system available.

Now, to the problem I alluded to: In building the prototype for Prism,
it quickly became apparent that, not only was there a need for a
separation of the precedural and the presentational aspects of the
data (this separation is the role of the UIMs), but another layer
of separation was required between the logical (symbolic) and the
physical representation of the data being manipulated by the program.

For example, Ingres has a textual data element which can store up
to 2000 characters (called text I believe), however, in an application,
I may have entites called `address' or `comments' which are of 
type text for ingres but of type `string' for another database.
In addition, this logical description of the data is where I would
like to place my presentational information such as the fact that
a date is three numeric entities in the format dd/mm/yy.

Has anyone done any work on this logical entity to physical mapping
of data? For want of terminology, I have called the physical mapping
the data dictionary (which I believe is the correct term) and the
logical mapping to the data dictionary the `data definition'.

-david-
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
David Haynes
Geac Computers Canada Ltd.		Telephone: +1 416 475 0525
350 Steelcase Road West,		FAX      : +1 416 475 3847
Markham, Ontario, CANADA. L3R 1B3	UUCP     : utgpu!geac!david
	Official Keeper of the Canadian X11 Sources Repository