Since I'm a real (printer) implementor I guess it's time I chimed in. I
believe there are many among us who are currently involved in web
based application development. As such, we are predisposed to think
that developing on top of HTTP is the way to go since we are currently
more comfortable with it. However, so called "low level sockets
programming" is not as bad as it is being made out to be. There are
well defined APIs for TCP level programming on EVERY major OS (what do
you think web browsers/servers use anyway?). Furthermore, having
recently implemented an embedded web server, I can tell you that there
is no such thing as CGI or ASAPI for low end embedded systems. For
these systems (and I mean real printers here) it's all C code and
there is no advantage to building on HTTP rather than TCP.
Angelo Caruso
Xerox Corp.
----------
From: ipp-owner at pwg.org
To: "abochannek at cisco.com"@??.ibm.com
Cc: rdebry at us.ibm.com; "ipp at PWG.ORG"@??.ibm.com
Subject: Re: IPP> What is it we really need?
Date: Monday, January 06, 1997 6:16AM
Classification:
Prologue:
Epilogue:
Alex, in order to get a better handle on this issue, I'd appreciate some input
from
you that speaks to the implementation issues here. I think that Babek makes
some
compelling arguments in his responses to your note when he says that (my
paraphrasing)
1) He's rather use CGI and ASAPI tools than low-level sockets programming
2) Basing IPP on HTTP (at least on Microsoft platforms) lets programmers take
advantage of many existing APIs and systems services, e.g. security.
As someone who represents a developer of network dexices, can you illuminate
the rest of us on
the pros and cons of an HTTP based protocol -- from an IMPLEMENTOR'S point of
view?
---------------------- Forwarded by Roger K Debry/Boulder/IBM on 01/06/97 06:45
AM ---------------------------
ipp-owner @ pwg.org
01/04/97 08:25 PM
To: jkm @ underscore.com at internet
cc: ipp @ pwg.org at internet
Subject: Re: IPP> What is it we really need?
> Let's focus on a simple network printing protocol based on
> the IP protocol suite. Then, let's address the larger domain
> of "Internet Printing"...whatever that may mean.
Jay,
I am very glad to see you summarizing the current situation like you
did. I certainly feel supported by you and Harald that a straight TCP
client-server model would be a better approach.
One comment I would like to make about people chanting the "Stock HTTP
Server" mantra:
"The Common Gateway Interface, or CGI, is a standard for external
gateway programs to interface with information servers such as HTTP
servers."
This is the definition to be found on the NCSA Web pages. And from all
the implementation suggestions, it sure sounds like HTTP is only going
to be used for hand-through to the "external gateway program". Not
much benefit in using the "Stock HTTP Server".
Babak from Microsoft has pretty much made the same point in his mail
from a couple of days ago.
--
Alex Bochannek Phone & Fax : +1 408 526 51 91
Senior Network Analyst Pager : +1 408 485 90 92
Engineering Services Alpha Pager : (800) 225-0256 PIN 104536
Cisco Systems, Inc. Email : abochannek at cisco.com
170 West Tasman Drive, Bldg. E Pager Email : abochannek at beeper.cisco.com
San Jose, CA 95134-1706, USA