>>> supports "tcp:<portno>".
>
>> OK, we've opened up sockets. Now what do we do? What do I expect
>> from you, or you from me?
>
> The URL structure can spell that out just like it does for HTTP and
> FTP. I.e. what difference is there between following in either the
> transfer or the transport case?
>
> http://myhost/path/to/file.type
> ftp://myhost/path/to/file.type
> tcp://host:port/path/to/file.type-or-mime.type
>
> http uses mime-types to tell the user/browser what it is receiving.
>
> ftp requires tha the user know about the type, or that there be a
> filename extension to indicate the file type.
The file type indicates the kind of data to expect. The protocol name
indicates *how* the data will be sent and received.
But when the protocol is "tcp:" there is no information about *how*
the data will be received.
> A tcp implementation could specify a mime-type in the path, or a
> filename. This would imply that the person using such a URL would
> have to know about the service. That is my point. In the case
> where I have a context that contains a set of URLs, why can't I just
> connect to a TCP port and get some data, be it HTML, imagery, data
> or whatever? Most people would say this is too free form, not
> controlled enough.
But TCP is not enough information. How do I know which byte you will
send to me first? How do I know how that byte is encoded? What about
the next byte, and the next after that?
There is no standard way to even agree to how to get the URL from one
system to another over TCP except through a transfer protocol running
on top of TCP. TCP is not enough unless there is some agreement on
*how* to use TCP.
> I'm just asking, if simplicity and flexibility is what everyone
> wants through REST interfaces, then why do all references to
> resources need to use HTTP and go through a web server's servlet
> container, etc. Wouldn't it be easier to talk to them directly when
> there was well defined, expected behavior?
If there were some well-define, expected behavior then that could
work. But it would have to be defined above the level of "tcp:" since
that designation does not indicate whether we are using *your*
expected behavior, or *my* expected behavior, or the expected behavior
of "http:", or the expected behavior of "ftp:", "mailto:" or something
else, like xmpp.
Not everything has to go through http, and some other protocol may be
better in some or all cases. But you still have to know what that
proctocol is. "Talk to them directly" does not work unless you can
talk the same language.
You can talk directly to my http-based services, or you can talk
directly to my xmpp-based services, or anything else I provide. They
may actually be the same services on the backside if all I have is a
driver for http and a driver for xmpp, and those drivers go to the
same services. You could bypass the http and xmpp drivers if I
provided some other driver. But it would still be a driver, and you
would still have to know *how* to talk to it.
-Patrick
SPONSORED LINKS
| Computer software | Computer aided design software | Computer job |
| Soa | Service-oriented architecture |
YAHOO! GROUPS LINKS
- Visit your group "service-orientated-architecture" on the web.
- To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
- Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
