Conference bulova::decw_jan-89_to_nov-90

    
    I am commenting on the stuff that caught my attention:
    
    >NETWORK GRAPHICS
    
    >       Required:               X-WINDOWS
    
    >        Of interest:         *  NeWS 
    
    
    Why would the government be interested in NeWS?  It is not productized
    (read "production quality") yet!  I hope this RFI is not wired to
    favor Sun.  You must make the customer aware that the X extension
    mechanism is provided without overall server performance penalty.
    Comapare and contrast this with the performance degredation inherent
    in using a language interpreter in the server - this is the technique
    utilized by Sun to achieve extensibility in their NeWS server.
    
    Remember to state that NeWS has no clean way of implementing a "Print
    Screen" Functionality. 
    
    You will definitely be confronted by the bogus ethernet bandwidth
    argument (similar to the 'big' and 'little' endian chaff). Position
    the fact that X allows applications to read-back pixel values from
    the server, whereas NeWS is incapable of doing that.  This constraint
    on NeWS prevents it from cleanly implementing certain types of applic-
    ations.  THE "Print Portion of Screen" is a good example - of for
    that matter, any other application that depends on capturing an
    arbitrary portion of a workstation display.  This is a big weakness
    of NeWS, so be confident to harp on it.
    
    Also, feel free to denounce the harsh Postscript API - debugging
    and maintaining obscure Postscript routines, and the down-loading
    of functions to the server introduces perilous, and significant 
    application synchronization problems - a thing no vendor can prescribe
    clear antedotes to today.  
    
    Also, X is more of an accepted standard when compared to NeWS. 
    Just compare the wealth of existing X applications with NeWS!
    
    Remember that NeWS has a superior imaging model in theory - but be
    bold to remind the customer that no vendor has captalized on that
    advantage to date.        
    
    
    >Required:            *  NFS with XDR
    >                     *  user accessible RPC
    
    Digital has licensed NCS from Apollo and it is superior to
    Sun RPC.                                                  
    NCS has more industry support.
    
    >OPENLOOK...
    
    Even Sun has abondoned this AT&T stuff.  Argue that Openlook is
    merely a specification...not a product.
    
    And don't forget to elaborate on the contribution made by DIGITAL
    in establishing X as a standard.
    
    good luck,
    
    Kris...
    
    

    Bashing Sun's NeWS windowing system is probably not the best way
    to impress your client. I would suggest you simply tell Nasa that
    NeWS is a window system provided by Sun which we don't support.
    If they have any specific requests for functionality which they
    believe NeWS provides over X/DECwindows, then provide them with
    comparison info on features that DECwindows can provide to match
    the NeWS facilities.                    
    
    Joe.
    
    p.s. I agree with the technical points raised by -.1 I just think
    empahsizing the postive aspects of DECwindows serves Digitals purpose
    better than pointing out defects in NeWS.

Joe,

I have a copy of a S** response to a big RFI that they used in winning
a big workstation deal.

I am sorry if my comments implied a direct attack on our competition -
just that the rules of the game has been drastically rewritten !  We don't have
to stoop too low, but we need to be progressively aggressive.

Kris..

The type of activity that .1 was suggesting was not to simply bash Sun. We don't
want to do that. We want the customer to understand that specifying that they
want Xwindows and also wants News, and also wants Openlook is like trying buy
a car that looks like a Cadillac, a Chevy, and a Volkswagen all at the same
time. The RFP requirements are not satisfiable. The idea is that by voicing 
these objections, the RFP author will reconsider his position, and either change
the RFP or withdraw the request entirely. 

It provides vendors (like DEC) to do a better job of responding to the RFP.


Just an opinion.

Thanks for the great information on NeWS, can anyone help with some
    of the items below??
                                
TERMINAL EMULATION TO ACCESS HOST SYSTEMS
                                
   	Required:	      	VT100
                                
   	Desired as 	      	VT2XX (with ReGIS and port printing)
   	available option:     	VT3XX
   			     ** TEK4XXX
                             **   3278/9 (including mod 5, 1332 
                                column)
                             **   3179
                             **   3270PC/G and 3270PC/GX
USER INTERFACE                  
                                
   	Required:	      	Industry (de-facto) standard 
   			      	graphical user interface, for 
   			      	example OSF/Motif or OPEN LOOK
                            
1) Can we do it?                
2) When can we do it?           
3) Why is this a stupid requirement?
4) If we can't do it do we have a third party who can? 
5) Why the way we do it is better than anyone else?
   
Thanks again for the help.
       
   

Re: .5

DECterm has VT300 emulation with ReGIS but no port printing and no Tektronix
emulation.  There is a Tektronix emulator in the works but it hasn't been
announced yet so I'm not sure how much you can tell NASA about it.  I'll
leave the "defacto industry standard user interface" question for others to
answer.

				-- Bob

re .6

Bob,

actually, there is Tektronix emulation capability with xterm...here is what
the Ultrix manual pageshave to say....

[This is one good reason why DIGITAL has to continue support for xterm ;-) ]

"
DESCRIPTION
     The xterm command provides DIGITAL VT102 and Tektronix 4014
     terminal emulation and a standard terminal type for programs
     not aware of the X Window System directly.  The terminal
     resizing facilities built into the system are supported by
     xterm.
"

re .5

>TERMINAL EMULATION TO ACCESS HOST SYSTEMS
                                
>  	Required:	      	VT100
                                
>   	Desired as 	      	VT2XX (with ReGIS and port printing)
>   	available option:     	VT3XX
>   			     ** TEK4XXX
>                             **   3278/9 (including mod 5, 1332 
>                                column)
>                             **   3179
>                             **   3270PC/G and 3270PC/GX

Most of the above requirements are met with DIGITAL products with the
possible exception of the IBMS 3279 and 3270PC/G and 3270PC/GX...but
this is currently in the works.  It is an unannounced product so I suggest
you get more info from the product people.  

A contact person for the DECwindows  IBM 3270/79..etc.. terminal products is
Audrey Augun at FROSTY::AUGUN (I believe she has the internet X.25 portal
project too).


>USER INTERFACE                  
                                
>   	Required:	      	Industry (de-facto) standard 
>   			      	graphical user interface, for 
>   			      	example OSF/Motif or OPEN LOOK


Please explain in clear and polite sales lingo that OPENLOOK is not yet
a product!  It is only a specification.

Spend a good amount of time in providing a clear understanding to your
*government* customer why DIGITAL is committed to standards.
Play on the whims of your customer -  NASA, as a government-funded agency,
should be interested in standards and the building of portable applications.

Let NASA view our strategy with User Interfaces as one that allows DIGITAL
to be in the driver's seat.  Our support for POSIX/OSF/Motif clearly provides
NASA with real value-added capabilities -  DIGITAL is working with various
standards organizations to drive standards and the market through innovation,
methodologies and tools that facilitate multi-platform development.
Don't forget to highlight the fact that our XUI	kit provides the substrate
for the Motif API package.

>1) Can we do it?

If DIGITAL cannot diliver, then nobody else can ;-)

>2) When can we do it? 

Sure..

>3) Why is this a stupid requirement?

I won't really say anything is stupid in here...just that we have aggressive
competition (won't mention any names) that would stretch the truth to win.

>4) If we can't do it do we have a third party who can?

I have confidence that DIGITAL can handle most of the requirements.

>5) Why the way we do it is better than anyone else?

Very difficult question...I would leave that one alone.  


BTW:  Have you tried seeking direct help from your area Ultrix Resource
      Center?  Looks like you are under a lot of pressure to deliver so
      much in a very short time.

Hope the above info helps somehow.

Kris...



                            

I don't understand how they could be requiring OSF/Motif.  OSF isn't due to
release it to the OSF members for another month or more.  NOBODY today can
claim to support OSF/Motif.  Of course, OSF probably will have delivered on
Motif before NASA takes delivery on these terminals, so it's probably safe to
tell them that, although our current product specs don't say we support
OSF/Motif, anybody who does claim they have it now is lying, and that we DO
intend to provide it, once OSF actually releases it to the members.

--PSW

re.            <<< Note 818.8 by ORPHAN::WINALSKI "Paul S. Winalski" >>>

>I don't understand how they could be requiring OSF/Motif.  OSF isn't due to
>release it to the OSF members for another month or more.  NOBODY today can
>claim to support OSF/Motif.  Of course, OSF probably will have delivered on
>Motif before NASA takes delivery on these terminals, so it's probably safe to
>tell them that, although our current product specs don't say we support
>OSF/Motif, anybody who does claim they have it now is lying, and that we DO
>intend to provide it, once OSF actually releases it to the members.

And, as most of it came from us, anyway, we will probably be the first...
        
        q
        
        

>.......NOBODY today can claim to support OSF/Motif....

Paul,

I believe that it is okay for us to say we support OSF/Motif as a *standard*....
(the basis for the Motif UI *product* ) ..that is quite different from saying
the we provide support for a Motif product *today*...

The point here is, SELL, SELL, SELL.....;^)

agreed?

Kris...

Agreed.  By "suport" I meant "have implemented and shipping in an announced,
deliverable product."  XUI is probably the thing that comes closest to that.

--PSW

Re: .7

Good point, but I think we'll be dropping xterm support in the future so
it might be best to check with a product manager before promising 4014
emulation to a customer.

				-- Bob

    
    I would hesitate to tell a customer that xterm was either supportable
    or a emulation of a VT10x (MIT can say whatever they want) unless and
    until Firmware QA certifies it as a conforming implementation and DEC
    agrees to fully support xterm.
    
    

Fred,

I do not intend to start a rathole.  I am pleased that you favor a  
"supportable" xterm.

flame...

Today, xterm is a supported X client (Ultrix DECwindows.). This is good!
It must be remembered that more than 90% of X11 users today, have
Unix systems  - and these users all require xterm to do their work.
So dropping support for xterm today is nothing less than abject misunderstanding
of the market forces that make a standard.

Standards need not be invented by DEC or some collective/self-interest
group behind locked doors.  If users decide that a product meets their needs,
and becomes popular, then there is very good chance that product could become
a 'defacto' standard - regardless of what DIGITAL and other interest groups
consider to be the best-fit for users.  NFS/TCP-IP is a good case study here
at DIGITAL.  For a long time, we literally 'fought' hard to prevent them
from 'contaminating' DIGITAL products - that was pure fool-hardiness; and
we lost that battle!

Shouldn't we learn from our past mistakes?

flame off.

Kris...

    
    I'm with you on this one (believe it or not).  I've been suggesting
    that xterm get shipped on the kit for a while now...
    
    

    Kris,
    
    If you  want  to  claim  that xterm is supported, and I have ANSI X3.64
    conformant software which does not work correctly on xterm (but does on
    a real VT100/VT200) -  who  do  I  bitch  at  to get the bug (in xterm)
    fixed?  Unless that person  is  clearly  identified,  and commitment is
    secured to fix bugs, I'm not going to say that my software supports the
    xterm.  It's just too risky.   For the same reason, we don't claim that
    our software supports any of the VTxxx clone makers. We can't fix their
    broken terminals, and we don't want to work around their bugs. 
    
    Now if xterm was shipped as part  of  the  kit  (and  I  agree  that it
    should) with the proper support in place, I'd gladly qualify against it
    and commit support from FMS/TDMS and DECforms.  Until  it  is gets that
    commitment, it doesn't exist.  If it works, fine, the xterm authors did
    a  good  job    of  implementing  the  X3.64  parser  (and  DEC-STD-070
    extensions).  We won't  stop  you  from  using it.  If it breaks, don't
    call us.
    
    James
    

Looks like every *X terminal* vendor (eg. Acer) prefers to use (supported?)
xterm.

It not my desire to discus unannounced products..so I won't..;-).
Which makes sense *today*?  Xterm or DECterm on an X terminal?

I am only interested in technical merits .  Anybody care to take a shot?

thanx,
Kris..

Re: .14

(Since you re-opened this...)

>Today, xterm is a supported X client (Ultrix DECwindows.). This is good!
>It must be remembered that more than 90% of X11 users today, have
>Unix systems  - and these users all require xterm to do their work.

DECterm works on Ultrix.  The problem is that some users have gotten used to
features on xterm that violate international standards and which aren't
supported in DECterm.  It's not clear to me just how many Ultrix users
"require" xterm to do their work, but I think at some point DECterm will
have to suport these "extra" features, probably in much the same way that
it supports VT52 mode (i.e. the user will have to choose between xterm
emulation *or* ANSI).

Another point the xterm fans bring up is performance, although batch scrolling
(available in DECterm using the batchScrollCount resource) evens the odds
quite a bit for people who don't care about reading their output as it scrolls
by.

As mentioned, another xterm feature is Tektronix emulation, which we intend
to support through an unannounced product that is currently under development.

Finally, there's quality.  DECterm has been tested and certified by the
same group that tests and certifies VT terminals, and although we didn't
have time to fix all the problems found during testing, the ANSI emulation
is in pretty good shape (being based on the VWS terminal emulator; we didn't
have to touch that code very much during DECterm development -- thanks,
Fred!)  I'm not sure what kind of testing xterm has been through; it's been
around for a while, but I don't know what mechanism there is for reporting
bugs and having someone fix them.

Re: .17

As far as I know DECterm hasn't been tested on third party X terminals.  One
problem is likely to be font names, unless the X terminals conform to X11R3.
As long as the X terminal uses the new (late 1988) font naming convention,
you can convince DECterm to use whatever fixed point fonts are out there
by setting the bigFontSetName and littleFontSetName resources.

If and when Digital comes out with an X terminal I'm sure that DECterm will
have no problems running on it (except for the problems it has running on
any other platform).

				-- Bob

    
    It shouldn't be one or the other, the answer should be BOTH should run
    on a "X Terminal".  If *we* put out a DWTerm with resident ROM for a
    server and terminal, then it should have DECterm or something like it.
    
    The only "real" advantage to xterm is in it's size - much smaller
    because it isn't carrying the DECwindows look & feel baggage.  As a
    terminal, it's a monumental hack.  And it should remain so.  Unix
    people love it and the sources are available so that what you don't
    like you can change.
    
    I disagree with Bob (even though he gave me a complement :-) - the
    xterm kludges (like the mouse) should *never* migrate into a real
    terminal product.  They are far worse than anything the VT52 ever
    did.
    
    While I have my problems with DECterm, it is a reasonable facsimile of
    the real thing, it's supportable and it's problems can be fixed.
    
    I will also say that there is a need for a simple-stupid DEC supported
    TEK4014 in addition to the "other" TEK emulator.  The 4014 would be
    a xtermish (i.e. small and compact) emulator that wouldn't be quite
    the overkill of the "other" emulator (and which could be bundled free
    instead of as a LP).  Come on, the code itself is simple.
    

The input provided by Bob, Fred and James are very useful.

I have only one more question.....[cynical...:-)..]

Do we support only products that meets some kind of spec....there is a lot
of flag-waving about ANSI and DECterm...

Is VAX C (DECterm written/or compiled in VAX C?) ANSI-compliant?

Food for thought...

Kris..

I'll answer .20 first since it's relevant to the base note.  Maybe Fred and
I should move our discussion of future directions to a new note.

Re: .20 kris

If you had a choice between buying an appliance than ran on 110 volts or
one that ran on 175 volts, which would you choose?  :-)

DEC is placing increasing emphasis on international standards.  In a perfect
world every application should be able to run on every platform, and while
we all know that the world isn't perfect, the closer we come to that ideal
the more our customers will benefit (i,e. the more valuable our products will
become).  Even if xterm's OSC functions are useful, the fact that they were
designed in a way that is incompatible with ISO (i.e. an application that uses
those sequences will hang on an ISO terminal) makes xterm a less valuable
product.

Given that there are customers using these non-standard features in xterm,
it's debatable whether we should: (a) let customers who want those features
continue to use xterm but don't provide them any support beyond that (which
seems to be what Fred is saying), (b) expand support for those features
by adding an xterm emulation mode in DECterm (which is what I'm hearing
from the Ultrix people) or (c) drop support for xterm altogether and encourage
customers to migrate to ISO or native DECwindows (which is the purists'
approach).

And yes, DECterm is compiled with VAXC.  I hope the VAXC people are looking
into migrating toward the ANSI standard.

Re: .19  Fred

>    The only "real" advantage to xterm is in it's size - much smaller
>    because it isn't carrying the DECwindows look & feel baggage.

That's an interesting point.  If DECterm is to replace xterm at some point
then we should consider providing stripped down versions for customers who
want the "lean and mean" look, e.g. no ReGIS, no Customize.  There actually
is a DECterm widget, with or without ReGIS, that's available for internal
use only, but there's a "small matter of programming" to connect this
widget to a pseudo terminal.
    
>    I disagree with Bob (even though he gave me a complement :-) - the
>    xterm kludges (like the mouse) should *never* migrate into a real
>    terminal product.  They are far worse than anything the VT52 ever
>    did.
    
You may be right, but that's not the direction the wind is blowing.  I think
the Ultrix people within DEC would like a DEC-supported terminal emulator
that fits into the DECwindows look and feel, but they don't want to give up
whatever software has been built up around the xterm extensions.

>    I will also say that there is a need for a simple-stupid DEC supported
>    TEK4014 in addition to the "other" TEK emulator.  The 4014 would be
>    a xtermish (i.e. small and compact) emulator that wouldn't be quite
>    the overkill of the "other" emulator (and which could be bundled free
>    instead of as a LP).  Come on, the code itself is simple.
    
Maybe TEK 4014 emulation could be included in a future version of DECterm
(also available in a "mix and match" stripped down version).  Which brings up
another interesting point: should DSG compete against its own Tektronix
emulator?  This gets back to the debate about whether we should charge money
for something that is (will be?) available for free in VWS.

				-- Bob

re -1

> Maybe Fred and I should move our discussion of future directions to a new note.


I have started one at 863  This is a very interesting topic because we have
many customers asking questions in this area.  Good you brought up the idea
of a new note.

Kris..