rcs@SEI.CMU.EDU (rCs) (08/24/89)
Reference Model
The P1201 User Interface reference model, shown below, is a layered model
which defines the program services and interfaces required for network-based,
bitmapped graphic user interface applications. For purposes of the UIDL/ADI
Working group Layers 0-3 a in the model could be replaced with a single user
interface toolkit, for example the Mac Toolkit or Presentation Manager.
Model Layer
Layer 6 Application
Layer 5 Dialogue
Layer 4 Presentation
Layer 3 Toolkit
Layer 2 Subroutine Foundation
Layer 1 Data Stream Interface
Layer 0 Data Stream Encoding
Domain
1. Define requirements for the application dialogue interface (between
layers 5 & 6 in the reference model).
2. Define requirements for a UIDL (layers 4 & 5 in the reference
model).
3. Define the binding mechanism for integrating toolkit level API's
into the presentation layer (between layers 3 & 4 in the reference
model).
Assumptions
1. Any proposed solution should support the toolkit API (between
layers 3 & 4 in the reference model) being defined by P1201.1.
2. Any proposed UIDL/API solution should work well on at least the X
Window System and a character based terminal (i.e. using Curses).
3. Any proposed solution should work well on low end platforms.
Proposals
1. Endorse the Seeheim terminology.
2. The ADI will not dictate specific data models for imaging,
graphics, and other areas in which existing standards apply. This
requires the use of other, existing standards in the development of
highly portable systems.
3. Preference will be given for a minimal solution that meets the
requirements.
REQUIREMENTS
ADI
1. Mixed control model (either/both UI or application control).
2. Presentation, or media, independent.
3. Programming language independent (C, Ada, Fortran).
4. Support dynamic requests for presentation services.
5. Functional/object interface?
UIDL
1. Support both presentation and dialogue.
2. Describe dynamic behavior.
3. Support dynamic requests for presentation services.
4. Toolkit independent.
5. Manipulate toolkit objects.
6. Support for generic objects.
Toolkit Binding Mechanism
1. Support multiple window systems (i.e. X, PM, Mac).
2. Support multiple toolkits (i.e. 1201.1, Motif, OpenLook).
3. Support character based terminals (i.e. curses on a VT220)
4. Not wreck existing toolkit interfaces.brsmith@umn-cs.CS.UMN.EDU (Brian R. Smith) (08/24/89)
rcs@SEI.CMU.EDU (rCs) writes: >Reference Model > The P1201 User Interface reference model, shown below, is a layered model >which defines the program services and interfaces required for network-based, >bitmapped graphic user interface applications. For purposes of the UIDL/ADI >Working group Layers 0-3 a in the model could be replaced with a single user >interface toolkit, for example the Mac Toolkit or Presentation Manager. < bitching on > Oh, please! Give me a break. ANOTHER %$*#@ Interface "standard"? Excuse me, I think I'm going to be ill. Programming-by-committee bothers me; why couldn't they just say "That Open Look thang is nice; let's implement that." No, that would be too easy. < bitching over > I think I'll buy a Mac and hide in a closet for a couple years until this settles down a bit. Brian
carlson@lance.tis.llnl.gov (John Carlson) (08/24/89)
After looking at several so-called "UIDL"s, I think they are in many ways similar to database so-called "4GL"s. Can we please merge 4GLs and UIDLs. What do you think? John Carlson carlson@tis.llnl.gov
rcs@SEI.CMU.EDU (rCs) (08/25/89)
> After looking at several so-called "UIDL"s, I think > they are in many ways similar to database so-called "4GL"s. > Can we please merge 4GLs and UIDLs. Yes, I agree they are very similar. I am not aware of any 4GLs which meet the requirement of being toolkit independent, however. I am not quite sure what you mean by "merge". There are UIMSs that provide database interfaces to the Application programmer. It might make sense if this API were exactly the same as an existing standard database interface so that an application developer could either send data to the UIMS for presentation or the database for storage by changing the output stream, for example. On the other hand the main purpose of a UIMS should be to separate application from user interface concerns. Towards this end, it wouldn't make sense for the UIMS to incorporate database calls. Robert C. Seacord
carlson@lance.tis.llnl.gov (John Carlson) (08/25/89)
In article <8908232256.AA12268@gg.sei.cmu.edu> rcs@SEI.CMU.EDU (rCs) writes: >Assumptions > > 1. Any proposed solution should support the toolkit API (between > layers 3 & 4 in the reference model) being defined by P1201.1. > > 2. Any proposed UIDL/API solution should work well on at least the X > Window System and a character based terminal (i.e. using Curses). I sumbit that any proposed solution should support several toolkits in layers 3 & 4. This will allow a programmer to add site-specific tools. >Toolkit Binding Mechanism > > 1. Support multiple window systems (i.e. X, PM, Mac). > > 2. Support multiple toolkits (i.e. 1201.1, Motif, OpenLook). Easily extensible to support site-specific tools. I can add one table and a record in another to add a new toolkit to my poor man's UIDL. Some UIDLs appear toolkit specific, without an easy way to add new toolkits. I am interested in the experiences of people who added another toolkit to an existing UIDL.