Jim Hebert writes:
> Ken MacLeod pointed me at this url:
>
> http://www.srvloc.org/
>
> I haven't had time to digest it, but Ken says this is a good place to look
> for the answer. His one line synopsis is:
>
> it's funny, because the SLP response is, ``you've got two running, which
> d'ya want?''

To expand on this, Service Location Protocol (SLP) is a draft IETF
standard for locating services within an area (your own computer,
your local network, someone elses local network, the organization,
or the Internet).

The basic scenario is that you ask an SLP server for a service using
a query (like a name, possibly some qualifiers) and SLP returns a list
of URLs (protocol, host, port) that you can use to access providers of
that service.

In this context, you could ask for all XML-RPC servers on the local
network or for Photoshop programs being used by J. Doe.  You can
also ignore SLP altogether and just provide a URL directly, no
different than now :-).

In any case, as Dave and Chuck suggest, this is a different layer and
can be handled outside of XML-RPC.


   -- Ken

http://www.software.ibm.com/ad/features/xmi.html

Dave

--------------------------------------
http://www.userland.com/directory.html

------------------------------------------------------------------------
Free Web-based e-mail groups -- http://www.eGroups.com

Ken MacLeod pointed me at this url:

http://www.srvloc.org/

I haven't had time to digest it, but Ken says this is a good place to look
for the answer. His one line synopsis is:

it's funny, because the SLP response is, ``you've got two running, which
d'ya want?''

jim

--
Linux has been deployed in mission critical, commercial environments with an
excellent pool of public testimonials...  Linux outperforms many other UNIXes
... Linux is on track to eventually own the x86 UNIX market... Linux is a
short/medium-term threat ... against NT Server. Linux's future strength against
NT server ... is fed by ... perceived Scaleability, Interopability,
Availability, and Manageability (SIAM) over NT. Linux can win....

Microsoft Internal Memo, annotated at http://www.opensource.org/halloween.html

------------------------------------------------------------------------
Free Web-based e-mail groups -- http://www.eGroups.com

This is a copy of a note I sent to Dave Winer on 8/16/98 about the XML RPC
spec posted at the URL below:

-----------------------------------------------------------------------------

Dave,
   I had a couple of comments on the XML RPC spec that I have been meaning
to pass along forever. Dunno why I left it in my outbox for so long. If
there's a better discussion forum for them than private e-mail, please aim
me at the right address. In the meantime, here are the comments. Some are
specific to the protocol, some are comments on terminology or wording. All
are intended to leave the current spec and functionality intact and extend
or clarify portions to make a more robust specification.

C.

-------------------------------------------------------------
Comments on the UserLand XML RPC specification by section
<http://www.scripting.com/frontier5/xml/code/rpc.html>

Header Requirements:
--------------------
For discovery purposes, it might be useful to document a standard URL that
RPC servers should support that will return information on the
server-specific URI for invoking XML RPCs. Much along the lines of a
robots.txt file, a xmlrpc.txt file could contain a sample URI template that
could be parameterized to show remote RPC clients how to correctly invoke
the RPC mechanism on a give server.

For example, a client's first handshake with a RPC server on start-up might
begin with a request for <http://someserver.com/xmlrpc.txt>. That document
could specify the URI and MIME type for incoming XML RPC requests. I.e.

/RPC2
text/xml

The client could then know to construct request headers with the specified
URI and MIME type without having to depend on a hard-wired format or URI.
This allows one client to work with a variety of RPC servers that have
different URI formats. Since the RPC standard specifically states that the
URI is unspecified, it really needs to be discoverable on a server by
server basis. After the initial discovery, subsequent RPC calls to the same
server will be made directly without the overhead of rediscovering the URI
and MIME type.

The reason for specifying the MIME type in addition to the URI in the .txt
file is that many Web servers invoke filters, plug-ins, or back-end CGI
processes based on MIME type instead of the URI value (Apache, for
example). Allowing alternate MIME types to appear in the XML RPC request
header would make it MUCH easier to integrate with non-Frontier Web
servers. Allowing the URI to be discovered means that an unknown client can
talk to an unknown server after discovering the URI format from a known
location.

Let me reiterate the importance of supporting other MIME types besides
text/xml for the object body. (Is this an approved MIME type, by the way?
If not, it should be text/x-xml.) Specifically, something like
text/x-xml-rpc2 would allow an Apache plug-in to handle RPC calls while
another plug-in deals with plain-vanilla XML (i.e., text/xml) not destined
for the XML RPC processor.

So I'd propose adding info to this section to define a way to discover the
URI and MIME type. If the discovery mechanism fails to return the
appropriate info, then the defaults should be as specified in the current
XML RPC document. (This proposal would eliminate the need for WebSTAR
filter plug-ins, for example.)

Payload format
--------------
The term "payload" is unique to this standard. The HTTP standard refers to
the content portion of a POST method (or any HTTP request) as an "object
body".

In the definition of <methodName>, "$" should be allowed in names as well.
This will greatly simplify some Java integration issues. In fact, it might
just be more appropriate to reference the URI encoding standard as far as
what characters are allowed in a method call. Servers that cannot support
certain characters would obviously never publish/support methods that use
them, so this shouldn't present a problem for any implementations.

Scalar values
-------------
String "scalars" absolutely need to specify an encoding scheme if the
default encoding for XML (UTF-8) isn't what is being used. Otherwise, this
document needs to be explicit about the encoding format for strings (again,
UTF-8 is assumed.)

int4 scalars need to specify big-endian or little endian. The assumption is
big-endian but isn't explicitly stated. Also, support for additional
integer types (e.g., int2, int1, int8) would be nice. Also, semantics
regarding signed/unsigned, etc.

Response Format
---------------
The Content-Type returned in the HTTP response header should match the MIME
type "discovered" as above, assuming discovery is enabled in the standard.
In the absence of discovery, the default is as specified.

The treatment of HTTP responses other than 200 OK needs to be addressed.
Specifically, the handling of URL redirects, server busy, and permission
violations has a direct bearing on the RPC protocol. Servers should be able
to redirect requests to other RPC servers, clients should be able to
recognize and retry busy servers, and clients should have an intelligent
way of handling permission problems. Simply returning 200 OK in all cases
is not necessarily desirable (or possible).

The "fault" mechanism seems somewhat unnecessary. Each method will have its
own semantics regarding what it means to receive a wrong number or type of
parameters, invalid arguments, etc. Rather than attempt to codify this in
the spec, it should just be left to each end of the RPC to determine
failure modes, error returns, messages, etc. I'd recommend striking this
portion of the spec or simply noting it as an implementation example and
not a requirement of the protocol.

Hopefully the above recommendations are in line with the current spec and
can be accomodated in some fashion. I think the URI/MIME discovery and
support for additional HTTP response codes are key. The other issues are
raised mostly for clarification.

C.

--_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
Chuck Shotton                                      BIAP Systems, Inc.
cshotton@...                                  http://www.biap.com/
                 "Shut up and eat your vegetables!!!"
------------------------------------------------------------------------
Free Web-based e-mail groups -- http://www.eGroups.com

I'm going to make comments to the original and the replies. Hope I keep it
straight.

At 6:22 AM -0800 11/11/98, Dave Winer wrote:
>Jim, Leonard:
>
>My opinion, in the spirit of getting things done and not getting lost
>trying to solve old problems that we've never been able to solve: Let the
>message go to the wrong app.

Namespace management should happen outside the scope of the XML RPC
mechanism. The process of bundling parameters and sending them to a
specific URL (i.e., HTTP server) is independent of how that URL is
discovered.

>Think about it, you can build a whole OS with this problem, like the Mac
>OS, where a filespec is not guaranteed to be unique. You could have two
>disks with the same name, and both could have an Apps folder that both
>contain a copy of PhotoShop.

However, in the case of a TCP/IP based protocol, you won't have two
applications listening on the same port on the same machine, so this is by
definition a non-issue. You won't have any ambiguity about which
application is getting the message.

>> Do we also want to provide an option to specify if the client wants
>>the XML-RPC "raw" or if the server should strip off the HTTP and/or XML-RPC
>>headers? I guess this should also apply to how responses are handled in
>>terms of who builds the HTTP header...

This seems largely outside the scope of the current UserLand proposal. How
you choose to wrap (or unwrap) the raw data after it transits the HTTP
connection delves into layers above the XML RPC mechanism and should
probably be considered someone else's problem. (It seems that there is a
"quick and dirty" approach and a "GUSI" approach to this IAC problem.
Before I blather on too much, let it be known that I ascribe to the former.)

>>
>>> HTTP-redirect: The main xml-rpc server will issue, at the HTTP level,
>>> the "service temporarily moved" header and the client will redirect the
>>> request to an xml-rpc server running on some other port. Currrently the DW
>>> spec for XML-RPC says it should always return 200 OK and I've thought this
>>> was shortsighted. Improving a next-gen implementation to take advantage of
>>> HTTP for the things it has done right like redirection seems like a good
>>> idea.

I think that is somewhat at odds with the initial reason for using HTTP.
This exercise isn't about having to implement full-blown HTTP servers in
every application. It is about trying to implement the absolute minimum
necessary to get messages from point A to point B. Throwing in all the
extra HTTP protocol overhead gains you nothing that cannot be managed
directly between the two "RPCs" communicating.

By definition, if the HTTP request was received at all, it was sent to the
proper RPC handler and *that* handler can package up appropriate response
information in the body of the response. There is no need to spread the
semantics of XML RPC responses across both the HTTP implementation and the
RPC implementation. HTTP is just a mechanism to get through firewalls and
it provides a simple ping-pong client request mechanism. To place any more
requirements on the HTTP portion of the XML RPC mechanism goes way beyond
what I understood as the original intent of this whole exercise. If you
want to build a Web server, build a Web server. (I'm quite tired of that,
by the way.) If you want to build a RPC mechanism, focus on that and
minimize the amount of time implementors have to waste on commodity
protocols and servers like HTTP.

>> I agree with you here!  Using redirect makes a lot of sense and
>>provides a lot of flexibility - not just in this case, but also for the
>>actual replacement/movement of an XML-RPC server.  (userland.com ->
>>scripting.com, for example).

But there is no need for all this additional HTTP complexity. If a given
RPC wants to inform a client that it should seek the service elsewhere,
that should be codified in the semantics of the RPC itself and not
overloaded on the HTTP mechanism.

>>
>>> HTTP-Proxy: The main xml-rpc server on the IANA port will issue a
>>> tcp-based request to the xml-rpc server running on this other port, and
>>> deliver the result back to the actual client. The purpose of this would be
>>> to allow applications which only implement the HTTP server to be reached
>>> through firewalls limiting to access to one port.
>>
>> I wonder if this (vs the redirect option) would be better done as a
>>"server global" preference?  I'm thinking that way because issues of needs
>>for proxy are really something to be set once (globally) and not on a
>>service by service.

The whole proxy problem is complicated by all sorts of issues with local
versus remote addresses, multiple proxies, and application side software
(e.g. NetNanny  or WebDoubler style apps) that gets in the way. It would be
helpful to have a system-wide mechanism for discovering appropriate proxy
configurations. Neither Macs nor PCs currently have this, though IBM's WBBI
initiative was an attempt (overkill) to address this. It should certainly
be considered as a candidate for Internet Config inclusion beyond what is
currently supported.

>> In other words, we'd reduce the IAC choices to two - HTTP or IAC
>>(AE/COM).  The HTTP choice of redirect vs. proxy would be determined by the
>>server.

Redirect shouldn't enter the picture. To proxy or not should be the only
concern.

>> HOWEVER, that brings up an interesting situation.  How do we deal
>>with duplicate names?  The user launches multiple copies of Photoshop (on
>>the Mac) or some SDI Windows app (Acrobat) - what should happen?  Special
>>error code so that the app can reregister with a different name, if it
>>wants?

Out of scope. Let whatever mechanism performs name registration and name
discovery arbitrate the name space. It doesn't have anything to do with the
XML RPC mechanism. This is all stuff that happens BEFORE the URL for the
RPC is known. There are plenty of existing protocols for name space
management and discovery. Pick one, don't reinvent it on top of the RPC
scheme.

>>> As far as the problem of dong all of this without tripping someone's PPP
>>> connection, this is doable as far as I can tell. On an OpenTransport
>>> machine, the last poster in the archive has it right -- use an automated
>>> interface for reconfiguing OT (eg some bogus ethernet settings if it comes
>>> to that) to avoid PPP.

This is only a problem on the Mac. All other TCP/IP implementations on
every machine I've ever tried allow XML RPC functions to happen over the
localhost address (i.e., 127.0.0.1). And it doesn't cause a PPP connection
to be established. Rather than waste effort trying to figure out if PPP
exists, it would be time much better spent to get Apple to fix their broken
TCP/IP implementation so localhost works for something other than ping.
Solving that problem means that the XML RPC mechanism can consistently rely
on being able to use 127.0.0.1 as the host for RPC calls within a single
machine. As it stands right now, Apple's lack of support for this
capability means we won't be shipping our next product on the Mac. Sad, but
true.

>>> On Windows
>>> 95, I'm not sure how machines without a NIC would do it, although some
>>> sort of null network adapter driver might be produced simply to get the OS
>>> something to bind an IP to. Windows machines seem to exhibit loopback-like
>>> behavior when you ping the machine's local address, even if the physical
>>> NIC has failed, so this would probably work. Perhaps even a bogus dialup
>>> networking setup with a static ip is enough to fool it, I don't know.

If TCP/IP is installed/enabled at all, I believe the localhost interface
works even in the absence of any real hardware. Someone else might want to
confirm that, since it is based on a PC sample of 1 and I am not in any way
a PC expert.

C.

--_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
Chuck Shotton                                      BIAP Systems, Inc.
cshotton@...                                  http://www.biap.com/
                 "Shut up and eat your vegetables!!!"
------------------------------------------------------------------------
Free Web-based e-mail groups -- http://www.eGroups.com

On Wed, 11 Nov 1998, Leonard Rosenthol wrote:

> At 7:51 AM -0500 11/11/98, Jim Hebert wrote:
> > You have to be able to content with multiple instances of an Application.
>
>  Hey - I had that in my response too ;).

pbblt. I said it first. ;-P

>
>
> > Sure, on the Mac, you have to REALLY try to get 2 instances of photoshop,
> > you have to copy the executable.
>
>  Or have two installation (like a 4.0 and a 5.0, or a beta version...)

Good point.

[snip]

> > Which, also suddenly makes me realize that the entire previous thread is
> > so single-user centric. That there would be only one instance of Photoshop
> > was a good enough assumption, unless you're on a giant SGI machine with
> > Photoshop for SGI being run over X11 by 4 different people, eh?
>
>  Well, you don't have to worry about it for Photoshop ;) - but the
> point is valid!   I would focus more on the multiple instances on Windows
> problem, rather than the X client/server problem since the former is MUCH
> easier than the latter (X is funky!).

re: X being funky I talked a bit about that in the mail I just sent. I
don't see why it needs to be regarded specially, really. It's just a
*really* likely scenario where there are going to be multiple instances,
and it introduces an element of "we hd better get the right one" sicne
getting the wrong would could give your data the the wrong person at
worst, or at least simply fail to do what you wanted with your files
(permissions).

But, even ignoring multiuser systems, you need to get the right one,
because, stealing fromyour example above, if I have photoshop 4 and
photoshop 5 running, I'm going to want to make this request to the one
which has the capability to do what I want. Or, 2 copies of an identical
app, but each started with different command line options, environment, or
something, which makes them different. (Heck, 2 instances of the explorer
viewing 2 different directories, if you send "delete everything" to one of
them hoping to clear the directory, you'd better get the right one!

[my suggestion for using more descriptive names deleted]

>  I had suggested in my message that the server simply return an
> error code (service already exists), and let the client decide what to
> register as (or not to reregister).  However, I don't have a preference
> either way...

Humm... well, that might be the way to go. At least then the user could
have some control over would the name of the service will eventually be,
and account for that in the script that' sgoing to be talking to the app.
Having some marginally predicatable-at-runtime name assigned to your
"applicatin's service" seems to suck, eh?

At the same time, it also seems like then you'd want to have the name that
the app registers itself as configurable either on the command line, via
the environment, or something. If you knew darn well you'd never get away
with registering 'photoshop' then perhaps you couldjust plan on always
shooting directory for 'jim-hebert-photoshop-bitch' and not have to pester
the user about this "failure" during starup (especially important for apps
that are going to be faceless, eh?).

Whew, I've brain dumped and I still think that the problem is a thorny
one. It almost makes me wonder if accounting for all these angles, by the
time you're done, won't have brought your complexity up to that of web dav
(not as complex as suspected, shown on www.scripting.com yesterday) which
has some sort of "servicelocator" I believe (though I'm totally dav
stupid). If that's the case, I wonder if it's better just to call this
simple to implement, lightweight thing we have now for what it is: useful
in specific instances, but not robust enough to deal with a variety of
problems? I'm not trying to becynical, I just don't want to brain-sweat
xml-rpc through some planning stage where it grows beyond what it should
before being abandoned in favor of something already designed for the same
problem cases.



jim


------------------------------------------------------------------------
Free Web-based e-mail groups -- http://www.eGroups.com

On Wed, 11 Nov 1998, Leonard Rosenthol wrote:

>  Do we also want to provide an option to specify if the client wants
> the XML-RPC "raw" or if the server should strip off the HTTP and/or XML-RPC
> headers? I guess this should also apply to how responses are handled in
> terms of who builds the HTTP header...

I'm not entirely grasping the point, so I'll say I don't have a pref? ;-P

> > HTTP-redirect: The main xml-rpc server will issue, at the HTTP level,
> > the "service temporarily moved" header and the client will redirect the
> > request to an xml-rpc server running on some other port. Currrently the DW
> > spec for XML-RPC says it should always return 200 OK and I've thought this
> > was shortsighted. Improving a next-gen implementation to take advantage of
> > HTTP for the things it has done right like redirection seems like a good
> > idea.
>
>  I agree with you here!  Using redirect makes a lot of sense and
> provides a lot of flexibility - not just in this case, but also for the
> actual replacement/movement of an XML-RPC server.  (userland.com ->
> scripting.com, for example).

Totally, that's the more obvious use of "service moved" that I hadn't even
really thought about. =)

(forest for the trees, jim, forest for the trees! ;-)

> > HTTP-Proxy: The main xml-rpc server on the IANA port will issue a
> > tcp-based request to the xml-rpc server running on this other port, and
> > deliver the result back to the actual client. The purpose of this would be
> > to allow applications which only implement the HTTP server to be reached
> > through firewalls limiting to access to one port.
>
>  I wonder if this (vs the redirect option) would be better done as a
> "server global" preference?  I'm thinking that way because issues of needs
> for proxy are really something to be set once (globally) and not on a
> service by service.
>
>  In other words, we'd reduce the IAC choices to two - HTTP or IAC
> (AE/COM).  The HTTP choice of redirect vs. proxy would be determined by the
> server.

I see what you're saying, totally, and think that would be a good way to
implement it, though I wouldn't go so far as to say it's a mandatory
implementation detail. Some power user on their linux/perl setup might
have specific reasons for putting someontheir own ports and not others.
(One easy example is that I host both 'net accessible methods and
intranet-only methods and by putting some on unreachable ports I use the
firewall to my advantage.) So, an implementation focused on ease of use
for the lightweight scripter who really is just intersted in cross
platform quark and photoshop scripting would do it your way, but the
implementation focused on the flexibility of a company with both an
extranet and an intranet or sorts (in xml-rpc terms) would do it my way.
=)

>  Sounds good to me.  Also, there should be nothing stopping a
> service from doing multiple registrations with different modes.

Sure.

>
>  HOWEVER, that brings up an interesting situation.  How do we deal
> with duplicate names?  The user launches multiple copies of Photoshop (on
> the Mac) or some SDI Windows app (Acrobat) - what should happen?  Special
> error code so that the app can reregister with a different name, if it
> wants?

You must have been writing this while I was writing my first followup. =)

> > As far as the problem of dong all of this without tripping someone's PPP
> > connection, this is doable as far as I can tell. On an OpenTransport
> > machine, the last poster in the archive has it right -- use an automated
> > interface for reconfiguing OT (eg some bogus ethernet settings if it comes
> > to that) to avoid PPP.
>
>  That assumes the config exists!  I don't believe that you can
> programmitically create a new setting.

Install it whenyou install the app? It wouldn't induce the need for a
reboot, even.

[windows 95 dummy nic suggestion, I plotchered the text accidentally and
don't feel like pasting it in to fix it]

>
>  Same problem - the user would have to have this already (or be
> told how to create one).  You can't create it on the fly :(.

Sure, but you can doit when you install the app. On windows that's almost
for-sure a reinstall anyways due to the regisry,  busy dlls, or whatever
it isthat makes yoou windows users reboot so mcuh. ;-)

> > And, of course, the portservers themselves could "listen" alternatively in
> > a COM/AE/whatever mode if doing a tcp based port finder wasn't tenable.
>
>  Which would make sense - then you just have to test for "using PPP"
> or something.  I believe that is doable.

Sure, at least on macos I've seen things that say "wait for PPP to go up
before opening TCP" or something specifically to allow you to start an app
that will use tcp/ip without tripping your ppp dialer.

Thanks for some great feedback,
jim

--
Linux has been deployed in mission critical, commercial environments with an
excellent pool of public testimonials...  Linux outperforms many other UNIXes
... Linux is on track to eventually own the x86 UNIX market... Linux is a
short/medium-term threat ... against NT Server. Linux's future strength against
NT server ... is fed by ... perceived Scaleability, Interopability,
Availability, and Manageability (SIAM) over NT. Linux can win....

Microsoft Internal Memo, annotated at http://www.opensource.org/halloween.html

------------------------------------------------------------------------
Free Web-based e-mail groups -- http://www.eGroups.com

At 6:22 AM -0800 11/11/98, Dave Winer wrote:
> Think about it, you can build a whole OS with this problem, like the Mac
> OS, where a filespec is not guaranteed to be unique. You could have two
> disks with the same name, and both could have an Apps folder that both
> contain a copy of PhotoShop.

	 A filespec IS guaranteed to be unique - a pathname (which is NOT
how you specify files/folders on the Mac) is not, however.


> Same problem with the namespace for Apple Events. We route the messages to
> apps based on creator ID. So if you have two PhotoShops running, you're
> hosed. It's a random walk.

	 However, that's a good point.


LDR
----------------------------------------------------------------------------
Leonard Rosenthol 	 <mailto:leonardr@...>
Designated Free Electron                (612) 766-4718 (Minn)
Adobe Systems Incorporated              (215) 233-5270 (Philly)

PGP Fingerprint: 8CC9 8878 921E C627 0BC1  15BB FC19 64A9 0016 1397

------------------------------------------------------------------------
Free Web-based e-mail groups -- http://www.eGroups.com

On Wed, 11 Nov 1998, Dave Winer wrote:

> Jim, Leonard:
>
> My opinion, in the spirit of getting things done and not getting lost
> trying to solve old problems that we've never been able to solve: Let the
> message go to the wrong app.
>
> Think about it, you can build a whole OS with this problem, like the Mac
> OS, where a filespec is not guaranteed to be unique. You could have two
> disks with the same name, and both could have an Apps folder that both
> contain a copy of PhotoShop.
>
> Same problem with the namespace for Apple Events. We route the messages to
> apps based on creator ID. So if you have two PhotoShops running, you're
> hosed. It's a random walk. Anyway, it's never been a major support headache
> for us. Most people never encounter this limit. It's a common sense thing.
> If you have two copies of PhotoShop running and your system isn't
> functioning properly, quit one of the copies. D'oh! The workaround is easy
> and it's (relatively) obvious. The assumption is that the user knows how
> systems work and you can't get very far if you don't.
>
> Dave

I disagree, however, because of the case of the multiuser system, like WTS
or a unix machine. You say you'd like a solution that's viable across
platforms to unix as well, then you'll need to deal with this.
A unix environment with people using NCD dumb x-terminals to run all their
apps off of a 4 ultrasparc processor solaris 2.6 installation won't get
very far if they're a little CAD workgroup looking to automate things and
their automations all involve the same CAD app.

If it were just the single user os's, like NT (ignoring WTS) 95 and MacOS,
that approach would probably be ok (and has been so far).

The other implication of lettingit go to the wrong places is security
related. If I can register an app with the same "signature" as yours and
get a 50/50chance of getting your traffic,that's a pretty powerful way to
masquerade as your service, capture your data, etc. If the methodcall
takes a username and password paramter in addition to the data, nowI've
got those too.

jim


------------------------------------------------------------------------
Free Web-based e-mail groups -- http://www.eGroups.com

Further, to followup my own message, it's an OS thing. We should get Bill,
Steve and Linus together to figure this one out. Dave

At 06:22 AM 11/11/98 -0800, you wrote:
>Jim, Leonard:
>
>My opinion, in the spirit of getting things done and not getting lost
>trying to solve old problems that we've never been able to solve: Let the
>message go to the wrong app.
>
>Think about it, you can build a whole OS with this problem, like the Mac
>OS, where a filespec is not guaranteed to be unique. You could have two
>disks with the same name, and both could have an Apps folder that both
>contain a copy of PhotoShop.
>
>Same problem with the namespace for Apple Events. We route the messages to
>apps based on creator ID. So if you have two PhotoShops running, you're
>hosed. It's a random walk. Anyway, it's never been a major support headache
>for us. Most people never encounter this limit. It's a common sense thing.
>If you have two copies of PhotoShop running and your system isn't
>functioning properly, quit one of the copies. D'oh! The workaround is easy
>and it's (relatively) obvious. The assumption is that the user knows how
>systems work and you can't get very far if you don't.
>
>Dave
>
>
>At 08:45 AM 11/11/98 -0500, you wrote:
>>At 7:20 AM -0500 11/11/98, Jim Hebert wrote:
>>> I want to flesh out the idea of the port server, as I imagine it.
>>
>> OK...As good a place to start as any...
>>
>>
>>> A port
>>> server is just some xml-rpc server, that happens to sit on the IANA
>>> assigned xml-rpc port.
>>
>> Or on 80 for Dave ;).
>>
>>
>>> In any case, this xml-rpc server sits there on the appropriate port. It
>>> can receive a method call that says "register service Photoshop" and an
>>> optional parameter of what port it would like to run on. The xml-rpc
>>> server would then respond with either a negative or affirmative. various
>>> nuances like, the photoshop service could indicate it is only willing to
>>> register at that port (for quick implementatins that refuse to be
>>> port-flexible) or it could indicate that the server may return an
>>> alternative port # which is free for it to use. This registration can also
>>> accomodate the other LDR/DW endorsed method of doing platform native IAC
>>> (the "doXML" idea) via one of its paramters.
>>
>> Sounds pretty reasonable....
>>
>> Do we also want to provide an option to specify if the client wants
>>the XML-RPC "raw" or if the server should strip off the HTTP and/or XML-RPC
>>headers? I guess this should also apply to how responses are handled in
>>terms of who builds the HTTP header...
>>
>>
>>> HTTP-redirect: The main xml-rpc server will issue, at the HTTP level,
>>> the "service temporarily moved" header and the client will redirect the
>>> request to an xml-rpc server running on some other port. Currrently the DW
>>> spec for XML-RPC says it should always return 200 OK and I've thought this
>>> was shortsighted. Improving a next-gen implementation to take advantage of
>>> HTTP for the things it has done right like redirection seems like a good
>>> idea.
>>
>> I agree with you here!  Using redirect makes a lot of sense and
>>provides a lot of flexibility - not just in this case, but also for the
>>actual replacement/movement of an XML-RPC server.  (userland.com ->
>>scripting.com, for example).
>>
>>
>>> HTTP-Proxy: The main xml-rpc server on the IANA port will issue a
>>> tcp-based request to the xml-rpc server running on this other port, and
>>> deliver the result back to the actual client. The purpose of this would be
>>> to allow applications which only implement the HTTP server to be reached
>>> through firewalls limiting to access to one port.
>>
>> I wonder if this (vs the redirect option) would be better done as a
>>"server global" preference?  I'm thinking that way because issues of needs
>>for proxy are really something to be set once (globally) and not on a
>>service by service.
>>
>> In other words, we'd reduce the IAC choices to two - HTTP or IAC
>>(AE/COM).  The HTTP choice of redirect vs. proxy would be determined by the
>>server.
>>
>>
>>> Rather than build some sort of precedence or way to specify a series of
>>> ordered preferences ("I'd like to use COM, but we can to do the HTTP proxy
>>> thing if we have to") the application attempting to register would simply
>>> be refused when requesting COM, and would need to dispatch a separate
>>> register request acking for the 2nd choice, in a scenario where com wasn't
>>> availible.
>>
>> Sounds good to me.  Also, there should be nothing stopping a
>>service from doing multiple registrations with different modes.
>>
>> HOWEVER, that brings up an interesting situation.  How do we deal
>>with duplicate names?  The user launches multiple copies of Photoshop (on
>>the Mac) or some SDI Windows app (Acrobat) - what should happen?  Special
>>error code so that the app can reregister with a different name, if it
>>wants?
>>
>>
>>> Presumably this registration would take place during application (eg
>>> photoshop) startup, and there would be an ancilary call during app
>>> shutdown. If the app crashed, oh well, peopl ewill end up at a port thatis
>>> unresponsive, no big deal, they will figure it out.
>>
>> Actually, on the Mac, there are hooks to allow apps to close things
>>down even on a crash.
>>
>>
>>> As far as the problem of dong all of this without tripping someone's PPP
>>> connection, this is doable as far as I can tell. On an OpenTransport
>>> machine, the last poster in the archive has it right -- use an automated
>>> interface for reconfiguing OT (eg some bogus ethernet settings if it comes
>>> to that) to avoid PPP.
>>
>> That assumes the config exists!  I don't believe that you can
>>programmitically create a new setting.
>>
>>
>>> On Windows
>>> 95, I'm not sure how machines without a NIC would do it, although some
>>> sort of null network adapter driver might be produced simply to get the OS
>>> something to bind an IP to. Windows machines seem to exhibit loopback-like
>>> behavior when you ping the machine's local address, even if the physical
>>> NIC has failed, so this would probably work. Perhaps even a bogus dialup
>>> networking setup with a static ip is enough to fool it, I don't know.
>>
>> Same problem - the user would have to have this already (or be told
>>how to create one).  You can't create it on the fly :(.
>>
>>
>>> And, of course, the portservers themselves could "listen" alternatively in
>>> a COM/AE/whatever mode if doing a tcp based port finder wasn't tenable.
>>
>> Which would make sense - then you just have to test for "using PPP"
>>or something.  I believe that is doable.
>>
>>
>>LDR
>>----------------------------------------------------------------------------
>>Leonard Rosenthol 	 <mailto:leonardr@...>
>>Designated Free Electron                (612) 766-4718 (Minn)
>>Adobe Systems Incorporated              (215) 233-5270 (Philly)
>>
>>PGP Fingerprint: 8CC9 8878 921E C627 0BC1  15BB FC19 64A9 0016 1397
>>
>>------------------------------------------------------------------------
>>For the absolute lowest price on software visit:
>>http://www.bottomdollar.com/egroups/
>>
>>Free Web-based e-mail groups -- http://www.eGroups.com
>>
>>
>
>--------------------------------------
>http://www.userland.com/directory.html
>
>------------------------------------------------------------------------
>Sponsored by NextCard Internet Visa.
>http://ads.egroups.com/click/137/1
>
>
>Free Web-based e-mail groups -- http://www.eGroups.com
>
>

--------------------------------------
http://www.userland.com/directory.html

------------------------------------------------------------------------
Free Web-based e-mail groups -- http://www.eGroups.com

On Wed, 11 Nov 1998, Leonard Rosenthol wrote:

> At 8:15 AM -0500 11/11/98, Jim Hebert wrote:
> > Argh, followup to myself again, but Windows Terminal server (and the
> > predecessor Citrix products) is another case of a multiuser system you'll
> > want to accomodate. So it's not just a unix problem. =)
> >
>  I think Windows terminal server (or whatever it's called this week)
> along with the X problem is a situation that is much harder to handle and
> address than the others since there are questions about just where the
> software lives and what machine you are addressing with the request.

Perhaps it's representative of our relative comfort levels working within
an X11 style environment (or not, maybe you're a clost X11 geek, I don't
know!), but I really don't believe that there really are "questions" about
where the software "lives."

The "central" machine (eg the WTS, or your big unix box serving up X11
apps) is the machine where the software lives. There can be NO other
interpretation, for if we suggest it might be wherever the display is,
we're in trouble. The display might be a null display (eg a run an app but
I don't want to see its face so I tell it to dislpay on some bogus display
which is essentially the /dev/null of displays), or it might be the
display of an ancient NCD X-terminal dumb network-booting peice of
hardware.

I don't disagree that this makes things harder to deal with -- sure it
does, that's why I mentioned it. =) I just think these multiuser systems
need tobe handled appropriately.

It's not just X11, for unix people, either. Let's say my vt100-based mail
reader decided to participate in this scriptability. Now, my account is at
my local isp who has 52,000 individual accounts in the password file, and
at any given time 5,000 people are running the same terminal based mail
reader as me.

I started thinking that there needs to be some way to advertise who you're
trying to hook up with, the way people hold up signs at the airport saying
"Jenkins" when they're your limo driver. (Hebert has never appeared o the
sign of a limo driver, except my non-relatives Bobby Hebert or Guy Hebert
of US Football and NHL Hockey, respectively!) How do we do that?

well, perhaps xml-rpc servers like photoshop are already going to only
want to really hear from certain people, right? The current trip seems to
be host-based (ip-based) authentication, or maybe leaving it up to the
application to include credentials inside a method call.

My brainstorming from that point yields:

1) Have applications which might contest for being known as "photoshop"
advertise some preference on subnets they like to hear from, and the most
specific match of the subnet to the actual connection wins. If someone
wants to receive all calls, they might say 0.0.0.0 (ie *.*.*.*) but a
second app registering specifically for 208.214.200.0/255.255.255.0 (ie
208.214.200.*) and win.

I don't like this idea tho. I think it's clunky and that it sucks. It will
99% of the time result in a tie because the users will have all specified
"everybody" or "localhost" (think giant unix shell server) ro whatever.

2) encourage people to not register at names like 'photoshop' but rather
some very nit picky specific name (and on NT -- including WTS -- and
Unix's case, include the userid that the app is running as in the name
registration).

This also sucks because I want to write a sript on the other machine that
says "connect to photoshop" and distribute it to all sorts of people, not
some script which needs to figure out what the name registered is gong to
be based on phase of the moon and mother's maiden name of the user.

I see more mail comng in from you, so I'll quit now and go read that. =)


jim



------------------------------------------------------------------------
Free Web-based e-mail groups -- http://www.eGroups.com

Jim, Leonard:

My opinion, in the spirit of getting things done and not getting lost
trying to solve old problems that we've never been able to solve: Let the
message go to the wrong app.

Think about it, you can build a whole OS with this problem, like the Mac
OS, where a filespec is not guaranteed to be unique. You could have two
disks with the same name, and both could have an Apps folder that both
contain a copy of PhotoShop.

Same problem with the namespace for Apple Events. We route the messages to
apps based on creator ID. So if you have two PhotoShops running, you're
hosed. It's a random walk. Anyway, it's never been a major support headache
for us. Most people never encounter this limit. It's a common sense thing.
If you have two copies of PhotoShop running and your system isn't
functioning properly, quit one of the copies. D'oh! The workaround is easy
and it's (relatively) obvious. The assumption is that the user knows how
systems work and you can't get very far if you don't.

Dave


At 08:45 AM 11/11/98 -0500, you wrote:
>At 7:20 AM -0500 11/11/98, Jim Hebert wrote:
>> I want to flesh out the idea of the port server, as I imagine it.
>
> OK...As good a place to start as any...
>
>
>> A port
>> server is just some xml-rpc server, that happens to sit on the IANA
>> assigned xml-rpc port.
>
> Or on 80 for Dave ;).
>
>
>> In any case, this xml-rpc server sits there on the appropriate port. It
>> can receive a method call that says "register service Photoshop" and an
>> optional parameter of what port it would like to run on. The xml-rpc
>> server would then respond with either a negative or affirmative. various
>> nuances like, the photoshop service could indicate it is only willing to
>> register at that port (for quick implementatins that refuse to be
>> port-flexible) or it could indicate that the server may return an
>> alternative port # which is free for it to use. This registration can also
>> accomodate the other LDR/DW endorsed method of doing platform native IAC
>> (the "doXML" idea) via one of its paramters.
>
> Sounds pretty reasonable....
>
> Do we also want to provide an option to specify if the client wants
>the XML-RPC "raw" or if the server should strip off the HTTP and/or XML-RPC
>headers? I guess this should also apply to how responses are handled in
>terms of who builds the HTTP header...
>
>
>> HTTP-redirect: The main xml-rpc server will issue, at the HTTP level,
>> the "service temporarily moved" header and the client will redirect the
>> request to an xml-rpc server running on some other port. Currrently the DW
>> spec for XML-RPC says it should always return 200 OK and I've thought this
>> was shortsighted. Improving a next-gen implementation to take advantage of
>> HTTP for the things it has done right like redirection seems like a good
>> idea.
>
> I agree with you here!  Using redirect makes a lot of sense and
>provides a lot of flexibility - not just in this case, but also for the
>actual replacement/movement of an XML-RPC server.  (userland.com ->
>scripting.com, for example).
>
>
>> HTTP-Proxy: The main xml-rpc server on the IANA port will issue a
>> tcp-based request to the xml-rpc server running on this other port, and
>> deliver the result back to the actual client. The purpose of this would be
>> to allow applications which only implement the HTTP server to be reached
>> through firewalls limiting to access to one port.
>
> I wonder if this (vs the redirect option) would be better done as a
>"server global" preference?  I'm thinking that way because issues of needs
>for proxy are really something to be set once (globally) and not on a
>service by service.
>
> In other words, we'd reduce the IAC choices to two - HTTP or IAC
>(AE/COM).  The HTTP choice of redirect vs. proxy would be determined by the
>server.
>
>
>> Rather than build some sort of precedence or way to specify a series of
>> ordered preferences ("I'd like to use COM, but we can to do the HTTP proxy
>> thing if we have to") the application attempting to register would simply
>> be refused when requesting COM, and would need to dispatch a separate
>> register request acking for the 2nd choice, in a scenario where com wasn't
>> availible.
>
> Sounds good to me.  Also, there should be nothing stopping a
>service from doing multiple registrations with different modes.
>
> HOWEVER, that brings up an interesting situation.  How do we deal
>with duplicate names?  The user launches multiple copies of Photoshop (on
>the Mac) or some SDI Windows app (Acrobat) - what should happen?  Special
>error code so that the app can reregister with a different name, if it
>wants?
>
>
>> Presumably this registration would take place during application (eg
>> photoshop) startup, and there would be an ancilary call during app
>> shutdown. If the app crashed, oh well, peopl ewill end up at a port thatis
>> unresponsive, no big deal, they will figure it out.
>
> Actually, on the Mac, there are hooks to allow apps to close things
>down even on a crash.
>
>
>> As far as the problem of dong all of this without tripping someone's PPP
>> connection, this is doable as far as I can tell. On an OpenTransport
>> machine, the last poster in the archive has it right -- use an automated
>> interface for reconfiguing OT (eg some bogus ethernet settings if it comes
>> to that) to avoid PPP.
>
> That assumes the config exists!  I don't believe that you can
>programmitically create a new setting.
>
>
>> On Windows
>> 95, I'm not sure how machines without a NIC would do it, although some
>> sort of null network adapter driver might be produced simply to get the OS
>> something to bind an IP to. Windows machines seem to exhibit loopback-like
>> behavior when you ping the machine's local address, even if the physical
>> NIC has failed, so this would probably work. Perhaps even a bogus dialup
>> networking setup with a static ip is enough to fool it, I don't know.
>
> Same problem - the user would have to have this already (or be told
>how to create one).  You can't create it on the fly :(.
>
>
>> And, of course, the portservers themselves could "listen" alternatively in
>> a COM/AE/whatever mode if doing a tcp based port finder wasn't tenable.
>
> Which would make sense - then you just have to test for "using PPP"
>or something.  I believe that is doable.
>
>
>LDR
>----------------------------------------------------------------------------
>Leonard Rosenthol 	 <mailto:leonardr@...>
>Designated Free Electron                (612) 766-4718 (Minn)
>Adobe Systems Incorporated              (215) 233-5270 (Philly)
>
>PGP Fingerprint: 8CC9 8878 921E C627 0BC1  15BB FC19 64A9 0016 1397
>
>------------------------------------------------------------------------
>For the absolute lowest price on software visit:
>http://www.bottomdollar.com/egroups/
>
>Free Web-based e-mail groups -- http://www.eGroups.com
>
>

--------------------------------------
http://www.userland.com/directory.html

------------------------------------------------------------------------
Free Web-based e-mail groups -- http://www.eGroups.com

At 8:15 AM -0500 11/11/98, Jim Hebert wrote:
> Argh, followup to myself again, but Windows Terminal server (and the
> predecessor Citrix products) is another case of a multiuser system you'll
> want to accomodate. So it's not just a unix problem. =)
>
	 I think Windows terminal server (or whatever it's called this week)
along with the X problem is a situation that is much harder to handle and
address than the others since there are questions about just where the
software lives and what machine you are addressing with the request.


LDR
----------------------------------------------------------------------------
Leonard Rosenthol 	 <mailto:leonardr@...>
Designated Free Electron                (612) 766-4718 (Minn)
Adobe Systems Incorporated              (215) 233-5270 (Philly)

PGP Fingerprint: 8CC9 8878 921E C627 0BC1  15BB FC19 64A9 0016 1397

------------------------------------------------------------------------
Free Web-based e-mail groups -- http://www.eGroups.com

At 7:51 AM -0500 11/11/98, Jim Hebert wrote:
> You have to be able to content with multiple instances of an Application.

	 Hey - I had that in my response too ;).


> Sure, on the Mac, you have to REALLY try to get 2 instances of photoshop,
> you have to copy the executable.

	 Or have two installation (like a 4.0 and a 5.0, or a beta version...)


> On windows, it seems to vary with the
> application, simpler ones allow you to have multiple intances while larger
> ones feign this by allowing you to click on the icon again, and you get
> a new window, but there was some messaging back to the already-running
> copy to make this happen.

	 Basically, you are correct.

	 For example, Adobe applications (except Acrobat, I believe) all
only allow for a single instance of the application to run.  This is
primarily due to the fact that we're MDI apps and it's more logical this
way.   Acrobat, like MSIE, is an SDI app, and so you get one copy per
document.


> Which, also suddenly makes me realize that the entire previous thread is
> so single-user centric. That there would be only one instance of Photoshop
> was a good enough assumption, unless you're on a giant SGI machine with
> Photoshop for SGI being run over X11 by 4 different people, eh?

	 Well, you don't have to worry about it for Photoshop ;) - but the
point is valid!   I would focus more on the multiple instances on Windows
problem, rather than the X client/server problem since the former is MUCH
easier than the latter (X is funky!).


> I don't have an immediate answer for this. Perhaps the inbound request for
> the "photoshop" service would be met with "request ambigious, please try
> again among the following choices
>
> photoshop-jhebert-1345
> photoshop-dwiner-2464
>
> where, in my imagination, those strings were made from unix uid and pid,
> but on other platforms oculd be made from anything, even something as
> simple as the launch time or a random number.
>
	 I had suggested in my message that the server simply return an
error code (service already exists), and let the client decide what to
register as (or not to reregister).  However, I don't have a preference
either way...


LDR
----------------------------------------------------------------------------
Leonard Rosenthol 	 <mailto:leonardr@...>
Designated Free Electron                (612) 766-4718 (Minn)
Adobe Systems Incorporated              (215) 233-5270 (Philly)

PGP Fingerprint: 8CC9 8878 921E C627 0BC1  15BB FC19 64A9 0016 1397

------------------------------------------------------------------------
Free Web-based e-mail groups -- http://www.eGroups.com

At 7:20 AM -0500 11/11/98, Jim Hebert wrote:
> I want to flesh out the idea of the port server, as I imagine it.

	 OK...As good a place to start as any...


> A port
> server is just some xml-rpc server, that happens to sit on the IANA
> assigned xml-rpc port.

	 Or on 80 for Dave ;).


> In any case, this xml-rpc server sits there on the appropriate port. It
> can receive a method call that says "register service Photoshop" and an
> optional parameter of what port it would like to run on. The xml-rpc
> server would then respond with either a negative or affirmative. various
> nuances like, the photoshop service could indicate it is only willing to
> register at that port (for quick implementatins that refuse to be
> port-flexible) or it could indicate that the server may return an
> alternative port # which is free for it to use. This registration can also
> accomodate the other LDR/DW endorsed method of doing platform native IAC
> (the "doXML" idea) via one of its paramters.

	 Sounds pretty reasonable....

	 Do we also want to provide an option to specify if the client wants
the XML-RPC "raw" or if the server should strip off the HTTP and/or XML-RPC
headers? I guess this should also apply to how responses are handled in
terms of who builds the HTTP header...


> HTTP-redirect: The main xml-rpc server will issue, at the HTTP level,
> the "service temporarily moved" header and the client will redirect the
> request to an xml-rpc server running on some other port. Currrently the DW
> spec for XML-RPC says it should always return 200 OK and I've thought this
> was shortsighted. Improving a next-gen implementation to take advantage of
> HTTP for the things it has done right like redirection seems like a good
> idea.

	 I agree with you here!  Using redirect makes a lot of sense and
provides a lot of flexibility - not just in this case, but also for the
actual replacement/movement of an XML-RPC server.  (userland.com ->
scripting.com, for example).


> HTTP-Proxy: The main xml-rpc server on the IANA port will issue a
> tcp-based request to the xml-rpc server running on this other port, and
> deliver the result back to the actual client. The purpose of this would be
> to allow applications which only implement the HTTP server to be reached
> through firewalls limiting to access to one port.

	 I wonder if this (vs the redirect option) would be better done as a
"server global" preference?  I'm thinking that way because issues of needs
for proxy are really something to be set once (globally) and not on a
service by service.

	 In other words, we'd reduce the IAC choices to two - HTTP or IAC
(AE/COM).  The HTTP choice of redirect vs. proxy would be determined by the
server.


> Rather than build some sort of precedence or way to specify a series of
> ordered preferences ("I'd like to use COM, but we can to do the HTTP proxy
> thing if we have to") the application attempting to register would simply
> be refused when requesting COM, and would need to dispatch a separate
> register request acking for the 2nd choice, in a scenario where com wasn't
> availible.

	 Sounds good to me.  Also, there should be nothing stopping a
service from doing multiple registrations with different modes.

	 HOWEVER, that brings up an interesting situation.  How do we deal
with duplicate names?  The user launches multiple copies of Photoshop (on
the Mac) or some SDI Windows app (Acrobat) - what should happen?  Special
error code so that the app can reregister with a different name, if it
wants?


> Presumably this registration would take place during application (eg
> photoshop) startup, and there would be an ancilary call during app
> shutdown. If the app crashed, oh well, peopl ewill end up at a port thatis
> unresponsive, no big deal, they will figure it out.

	 Actually, on the Mac, there are hooks to allow apps to close things
down even on a crash.


> As far as the problem of dong all of this without tripping someone's PPP
> connection, this is doable as far as I can tell. On an OpenTransport
> machine, the last poster in the archive has it right -- use an automated
> interface for reconfiguing OT (eg some bogus ethernet settings if it comes
> to that) to avoid PPP.

	 That assumes the config exists!  I don't believe that you can
programmitically create a new setting.


> On Windows
> 95, I'm not sure how machines without a NIC would do it, although some
> sort of null network adapter driver might be produced simply to get the OS
> something to bind an IP to. Windows machines seem to exhibit loopback-like
> behavior when you ping the machine's local address, even if the physical
> NIC has failed, so this would probably work. Perhaps even a bogus dialup
> networking setup with a static ip is enough to fool it, I don't know.

	 Same problem - the user would have to have this already (or be told
how to create one).  You can't create it on the fly :(.


> And, of course, the portservers themselves could "listen" alternatively in
> a COM/AE/whatever mode if doing a tcp based port finder wasn't tenable.

	 Which would make sense - then you just have to test for "using PPP"
or something.  I believe that is doable.


LDR
----------------------------------------------------------------------------
Leonard Rosenthol 	 <mailto:leonardr@...>
Designated Free Electron                (612) 766-4718 (Minn)
Adobe Systems Incorporated              (215) 233-5270 (Philly)

PGP Fingerprint: 8CC9 8878 921E C627 0BC1  15BB FC19 64A9 0016 1397

------------------------------------------------------------------------
Free Web-based e-mail groups -- http://www.eGroups.com

Argh, followup to myself again, but Windows Terminal server (and the
predecessor Citrix products) is another case of a multiuser system you'll
want to accomodate. So it's not just a unix problem. =)

jim

On Wed, 11 Nov 1998, Jim Hebert wrote:

> Hate to followup to myself, but another point fromthe original thread I'd
> like to answer: the idea that "there's no port shortage."
>
> You have to be able to content with multiple instances of an Application.
> Sure, on the Mac, you have to REALLY try to get 2 instances of photoshop,
> you have to copy the executable. On windows, it seems to vary with the
> application, simpler ones allow you to have multiple intances while larger
> ones feign this by allowing you to click on the icon again, and you get
> a new window, but there was some messaging back to the already-running
> copy to make this happen.
>
> In unix, you nearly always create new instances of your application.
>
> Which, also suddenly makes me realize that the entire previous thread is
> so single-user centric. That there would be only one instance of Photoshop
> was a good enough assumption, unless you're on a giant SGI machine with
> Photoshop for SGI being run over X11 by 4 different people, eh? How do you
> get ahold of the one you want? Clearly, if you want it to open some file
> and process it, you'd better get the right one in order to have the right
> permissions to read the file!
>
> So, now the question becomes, how do we handle choosing between multiple
> instances of an app, given that it can happen in both single and multiuser
> scenarios and making the right choice is probably important?
>
> I don't have an immediate answer for this. Perhaps the inbound request for
> the "photoshop" service would be met with "request ambigious, please try
> again among the following choices
>
> photoshop-jhebert-1345
> photoshop-dwiner-2464
>
> where, in my imagination, those strings were made from unix uid and pid,
> but on other platforms oculd be made from anything, even something as
> simple as the launch time or a random number.
>
> comments, please?
> jim
>
>

--
Linux has been deployed in mission critical, commercial environments with an
excellent pool of public testimonials...  Linux outperforms many other UNIXes
... Linux is on track to eventually own the x86 UNIX market... Linux is a
short/medium-term threat ... against NT Server. Linux's future strength against
NT server ... is fed by ... perceived Scaleability, Interopability,
Availability, and Manageability (SIAM) over NT. Linux can win....

Microsoft Internal Memo, annotated at http://www.opensource.org/halloween.html

------------------------------------------------------------------------
Free Web-based e-mail groups -- http://www.eGroups.com

Hate to followup to myself, but another point fromthe original thread I'd
like to answer: the idea that "there's no port shortage."

You have to be able to content with multiple instances of an Application.
Sure, on the Mac, you have to REALLY try to get 2 instances of photoshop,
you have to copy the executable. On windows, it seems to vary with the
application, simpler ones allow you to have multiple intances while larger
ones feign this by allowing you to click on the icon again, and you get
a new window, but there was some messaging back to the already-running
copy to make this happen.

In unix, you nearly always create new instances of your application.

Which, also suddenly makes me realize that the entire previous thread is
so single-user centric. That there would be only one instance of Photoshop
was a good enough assumption, unless you're on a giant SGI machine with
Photoshop for SGI being run over X11 by 4 different people, eh? How do you
get ahold of the one you want? Clearly, if you want it to open some file
and process it, you'd better get the right one in order to have the right
permissions to read the file!

So, now the question becomes, how do we handle choosing between multiple
instances of an app, given that it can happen in both single and multiuser
scenarios and making the right choice is probably important?

I don't have an immediate answer for this. Perhaps the inbound request for
the "photoshop" service would be met with "request ambigious, please try
again among the following choices

photoshop-jhebert-1345
photoshop-dwiner-2464

where, in my imagination, those strings were made from unix uid and pid,
but on other platforms oculd be made from anything, even something as
simple as the launch time or a random number.

comments, please?
jim

--
Linux has been deployed in mission critical, commercial environments with an
excellent pool of public testimonials...  Linux outperforms many other UNIXes
... Linux is on track to eventually own the x86 UNIX market... Linux is a
short/medium-term threat ... against NT Server. Linux's future strength against
NT server ... is fed by ... perceived Scaleability, Interopability,
Availability, and Manageability (SIAM) over NT. Linux can win....

Microsoft Internal Memo, annotated at http://www.opensource.org/halloween.html

------------------------------------------------------------------------
Free Web-based e-mail groups -- http://www.eGroups.com

On Tue, 10 Nov 1998, Jim Roepcke wrote:

> On Mon, 9 Nov 1998 16:47:25 -0800, Jim Roepcke wrote:
>
> >But a couple of months ago, I had a
> >conversation on the Script Meridian community list with Leonard Rosenthol
> >about XML-RPC, and embedding it in desktop apps to make them scriptable.
> >
> >I will try to find these messages in my archive, and post and URL here to a
> >web page with the messages from that thread.
>
> Okay, the pages aren't pretty, the UI is crummy, but it's there for you to
> read.  The main thread is called "XML-RPC with other apps?", started by
> Leonard Rosenthol, and there are a few spin-off threads.
>
> http://www.roepcke.com/xmlrpc/discussion1/bydate.shtml
> http://www.roepcke.com/xmlrpc/discussion1/byperson.shtml
> http://www.roepcke.com/xmlrpc/discussion1/bysubject.shtml
>
> Those are the indexes sorted by date, author+date, and subject+date.
>
> I'm sure the people on this list could easily fill in some of the other blanks
> to get a solid design for this kind of thing kickstarted.


Jim,

Great job showing up with the archive. It was just what I needed. I
remember now seeing the parts that made it to scripting.com coverage.

My take:

I want to flesh out the idea of the port server, as I imagine it. A port
server is just some xml-rpc server, that happens to sit on the IANA
assigned xml-rpc port. This can be a small, dedicated app, or something
Frontier can provide (presumably it would make more sense for people
running frontier touse a frontier-resident version, but you'd want the
other avenue, because as LDR pointed out, shipping with Frontier running
ain't going to fly).

In any case, this xml-rpc server sits there on the appropriate port. It
can receive a method call that says "register service Photoshop" and an
optional parameter of what port it would like to run on. The xml-rpc
server would then respond with either a negative or affirmative. various
nuances like, the photoshop service could indicate it is only willing to
register at that port (for quick implementatins that refuse to be
port-flexible) or it could indicate that the server may return an
alternative port # which is free for it to use. This registration can also
accomodate the other LDR/DW endorsed method of doing platform native IAC
(the "doXML" idea) via one of its paramters.

A quick stab at formalizing this would be:

registerService
    serviceName
    servicePort (what you'd like to get assigned to, optional)
    acceptOtherPort (if you're willing to be flexible onport #, optional)
    IACchoice  (request to use a specific way of communicating from here on
                out. My ideas for this paramter are things like:

HTTP-redirect: The main xml-rpc server will issue, at the HTTP level,
the "service temporarily moved" header and the client will redirect the
request to an xml-rpc server running on some other port. Currrently the DW
spec for XML-RPC says it should always return 200 OK and I've thought this
was shortsighted. Improving a next-gen implementation to take advantage of
HTTP for the things it has done right like redirection seems like a good
idea.

AE: Use apple-events, let the main xml-rpc server on the IANA port do all
the tcp work.

COM: Use com, see above.

HTTP-Proxy: The main xml-rpc server on the IANA port will issue a
tcp-based request to the xml-rpc server running on this other port, and
deliver the result back to the actual client. The purpose of this would be
to allow applications which only implement the HTTP server to be reached
through firewalls limiting to access to one port.  On a unix machine,
you'd probably use the loopback interface for this request.

Obviously if the service is going to let the xml-rpc server runnning on
the IANA port do all the tcp/ip talking, then the port# portions of the
request are irrelevant as it only needs to really specify the name and the
IAC type (eg AE or COM).

Rather than build some sort of precedence or way to specify a series of
ordered preferences ("I'd like to use COM, but we can to do the HTTP proxy
thing if we have to") the application attempting to register would simply
be refused when requesting COM, and would need to dispatch a separate
register request acking for the 2nd choice, in a scenario where com wasn't
availible.

Presumably this registration would take place during application (eg
photoshop) startup, and there would be an ancilary call during app
shutdown. If the app crashed, oh well, peopl ewill end up at a port thatis
unresponsive, no big deal, they will figure it out.

As far as the problem of dong all of this without tripping someone's PPP
connection, this is doable as far as I can tell. On an OpenTransport
machine, the last poster in the archive has it right -- use an automated
interface for reconfiguing OT (eg some bogus ethernet settings if it comes
to that) to avoid PPP. On Unix, it's the loopback interface. On Windows
95, I'm not sure how machines without a NIC would do it, although some
sort of null network adapter driver might be produced simply to get the OS
something to bind an IP to. Windows machines seem to exhibit loopback-like
behavior when you ping the machine's local address, even if the physical
NIC has failed, so this would probably work. Perhaps even a bogus dialup
networking setup with a static ip is enough to fool it, I don't know.

And, of course, the portservers themselves could "listen" alternatively in
a COM/AE/whatever mode if doing a tcp based port finder wasn't tenable.

Alot ofthis isn't new, but I think some of it might be, or might be futher
explorations of ideas fromthe previous discussions. Please share your
thoughts.

jim

--
Linux has been deployed in mission critical, commercial environments with an
excellent pool of public testimonials...  Linux outperforms many other UNIXes
... Linux is on track to eventually own the x86 UNIX market... Linux is a
short/medium-term threat ... against NT Server. Linux's future strength against
NT server ... is fed by ... perceived Scaleability, Interopability,
Availability, and Manageability (SIAM) over NT. Linux can win....

Microsoft Internal Memo, annotated at http://www.opensource.org/halloween.html

------------------------------------------------------------------------
Free Web-based e-mail groups -- http://www.eGroups.com

There were some good ideas in that discussion, like getting an XML parser
INIT into the Mac OS so that AppleScript people could do XML too.

BTW, the main source of ideas and frustration have been coming from my very
good friend Chuck Shotton (kind of like the friendship between Newt
Gingrich and the new Livingston fellow). Chuck, are you on this list? He
had a lot of suggestions yesterday. I'd like to see those posted to this
list.

Another BTW, I don't want to be the bottleneck. And I don't want to break
the apps we depend on for updating our customers. We actually use the
XML-RPC stuff, so I can't wake up one morning and change betty.rpc.server
and have everything still work.

Our current implementation of XML-RPC is like our support for IAC on System
6 before Apple did Apple Events. It allows us to build an infrastructure
before there is a standard. Very few if any of our scripts broke when we
transitioned from our own IAC to Apple's. The same sort of thing should
happen here, no matter who sets the standard, or if there are many
standards. I would like to see there be one standard of course, for the
practical reason that it means only one codebase to maintain.

Onward!

Dave

At 01:22 AM 11/10/98 -0800, you wrote:
>On Mon, 9 Nov 1998 16:47:25 -0800, Jim Roepcke wrote:
>
>>But a couple of months ago, I had a
>>conversation on the Script Meridian community list with Leonard Rosenthol
>>about XML-RPC, and embedding it in desktop apps to make them scriptable.
>>
>>I will try to find these messages in my archive, and post and URL here to a
>>web page with the messages from that thread.
>
>Okay, the pages aren't pretty, the UI is crummy, but it's there for you to
>read.  The main thread is called "XML-RPC with other apps?", started by
>Leonard Rosenthol, and there are a few spin-off threads.
>
>http://www.roepcke.com/xmlrpc/discussion1/bydate.shtml
>http://www.roepcke.com/xmlrpc/discussion1/byperson.shtml
>http://www.roepcke.com/xmlrpc/discussion1/bysubject.shtml
>
>Those are the indexes sorted by date, author+date, and subject+date.
>
>I'm sure the people on this list could easily fill in some of the other
blanks
>to get a solid design for this kind of thing kickstarted.
>
>Enjoy,
>
>Jim
>
>
>
>---
>Jim Roepcke - jim@...
>Roepcke Computing Solutions
>Victoria, BC, Canada
>http://www.roepcke.com/
>
>
>------------------------------------------------------------------------
>
>
>Free Web-based e-mail groups -- http://www.eGroups.com
>
>

--------------------------------------
http://www.userland.com/directory.html

------------------------------------------------------------------------
Free Web-based e-mail groups -- http://www.eGroups.com

On Mon, 9 Nov 1998 16:47:25 -0800, Jim Roepcke wrote:

>But a couple of months ago, I had a
>conversation on the Script Meridian community list with Leonard Rosenthol
>about XML-RPC, and embedding it in desktop apps to make them scriptable.
>
>I will try to find these messages in my archive, and post and URL here to a
>web page with the messages from that thread.

Okay, the pages aren't pretty, the UI is crummy, but it's there for you to
read.  The main thread is called "XML-RPC with other apps?", started by
Leonard Rosenthol, and there are a few spin-off threads.

http://www.roepcke.com/xmlrpc/discussion1/bydate.shtml
http://www.roepcke.com/xmlrpc/discussion1/byperson.shtml
http://www.roepcke.com/xmlrpc/discussion1/bysubject.shtml

Those are the indexes sorted by date, author+date, and subject+date.

I'm sure the people on this list could easily fill in some of the other blanks
to get a solid design for this kind of thing kickstarted.

Enjoy,

Jim



---
Jim Roepcke - jim@...
Roepcke Computing Solutions
Victoria, BC, Canada
http://www.roepcke.com/


------------------------------------------------------------------------
Free Web-based e-mail groups -- http://www.eGroups.com

Jim H,

I don't really know the answer to your question about if it's open or
proprietary.  Perhaps Dave will say.  But a couple of months ago, I had a
conversation on the Script Meridian community list with Leonard Rosenthol
about XML-RPC, and embedding it in desktop apps to make them scriptable.

I will try to find these messages in my archive, and post and URL here to a
web page with the messages from that thread.

The current spec is called "RPC2" inside frontier.  I don't see why anyone
couldn't make a new spec, call it RPC3 (or whatever), and implement clients
and servers with it (not just in Frontier, hopefully).

The following page describes this some more.

http://www.scripting.com/98/04/stories/simpleCrossNetworkScript.html

Note: From http://www.scripting.com/98/04/default.html:

"Clarification: Simple Cross-Network Scripting will work across COM and
Apple Events too. Those are networks, even if the process you're talking to
is on the same machine. We're going to try to get something going with Java
RMI too."

None of this SCNS stuff has happened yet but I think I heard recently that
this is back on track.

BTW, according to an exchange with Dave Winer about SCNS on the community
list, there's no reason why the SCNS stuff has to use XML, or even HTTP, or
even TCP/IP.  Hopefully it will be implemented that flexibly.

Jim R
------------------------------------------------------------------------
Free Web-based e-mail groups -- http://www.eGroups.com

Come on Jim it's really simple. If a new group changed things then we'd
support that too, if we can, alongside the XML-RPC spec that we currently
support, which is frozen; except for the possibility of adding new data
types. I'm showing flexibility, you should like that. Lots of possible
transports can fit behind betty.rpc.client. Dave

--------------------------------------
http://www.userland.com/directory.html

______________________________________________________________________
For the absolute lowest price on software visit:
http://www.bottomdollar.com/egroups/

Subscribe, unsubscribe, opt for a daily digest, or start a new e-group
at http://www.eGroups.com -- Free Web-based e-mail groups.

Perhaps someone can help clear up some confusion I have:

From yesterday at 
http://nirvana.userland.com/discussiongroup.root/public/msgReader$280

>      Our XML-RPC spec could expand in the future to allow transmission
>      of additional scalar types, such as object database addresses,but
>      that's the only kind of change we'll consider. It's frozen,
>      deployed, apps have been built on it, and more are on the way.

Today at  http://nirvana.userland.com/tickets/stories/ticketReader$11

>      PPS: One more thing, a very short-term item, let's get [5]XML-RPC
>      interfaces built everywhere. Want to change the spec? Go for it.
>      But be quick! Don't get bogged down in making it artful. Make it
>      work, make it low-tech, stay focused on performance and ease of
>      understanding.
>

Both of these statements were written by Dave Winer of Userland software.

I have 2 questions:

1) Don't these statements contradict each other? Or is Dave saying "go
    ahead, develop changes in the protocol, but just that Frontier's
    implementation is frozen"? Could someone clear this up?

2) Why is Userland software in a position to make these kind of statements,
    giving people red/green lights, about the evolution of this protocol?
    Is this protocol open, or proprietary to Userland? I've been on this
    (silent) list for quite some time, I have never seen a word of
    discussion about the protocol here -- is there a list where people
    other than Dave and his customers/users discuss the future of the
    protocol in some open manner more in keeping with bazaar style
    open development we keep reading so much about? Maybe I'm on
    the wrong list, I dunno....

    Along the same lines, why were so many XML-RPC applications deployed
    before this invitation (the only one if its kind I can find) to
    work on improving the protocol? Was there some "angle" for Userland?

A more substantiative question, is there a standardized way (by
standarized, I mean a way that several of the things implementing XML-RPC
will do now, not something that we can just make up on the spot) to
transmit, say, a gif? Or really, any general framework for dealing with
MIME types?

For instance, the reponse in a valid XML-RPC converstation is mandated to
be XML according to the docs I read. How do I return a custom generated
image? I really, really, hope the answer is not "return a url pointing at
some other cgi with a state #, then make a separate HTTP request to that
cgi and grab the image." I might want to post a rpc request saying "here's
my tiff image, please optimize it using whatever format it best and give
it back to me." Yes, I could cook up my own application specific struct
which included base64 encoded data, etc, etc, I'm not unimaginative. =)
I'm just wondering how much standardized, interapplication compatibility
was lost in the name of simplicity of implementation?

Also, it's unclear if xml-rpc implementations are expected to "degrade"
gracefully by trying to cope with value types they haven't seen before.
Ie, if we DO decide to add a <uint32> type or something, what is an older
implementation expected to do? I couldn't find anything on the userland
site about this. Is there any other site on the net that documents xm-rpc?

tia,
jim

--
Linux has been deployed in mission critical, commercial environments with an
excellent pool of public testimonials...  Linux outperforms many other UNIXes
... Linux is on track to eventually own the x86 UNIX market... Linux is a
short/medium-term threat ... against NT Server. Linux's future strength against
NT server ... is fed by ... perceived Scaleability, Interopability,
Availability, and Manageability (SIAM) over NT. Linux can win....

Microsoft Internal Memo, annotated at http://www.tuxedo.org/~esr/halloween.html

______________________________________________________________________
No tricks, no gimmicks - just a great intro rate for Internet users!
NextCard Internet VISA -- Apply online now!
http://ads.egroups.com/click/61/1/nextcard

Subscribe, unsubscribe, opt for a daily digest, or start a new e-group
at http://www.eGroups.com -- Free Web-based e-mail groups.

Hi there.  I'm very interested in xml-rpc
and I think it'll be a big winner.  Haven't
seen much about it lately.  I understand
Microsoft is working on an rfc (SOAP).  When will
they make it public?  Any other news?

thx,  Aaron Watters http://www.chordate.com


-----
Free e-mail group hosting at http://www.eGroups.com/
______________________________________________________________________
NextCard Internet VISA -- 2.9% intro APR
Earn free airline tickets WITH DOUBLE Rew@rds points.
http://ads.egroups.com/click/61/0/nextcard

Subscribe, unsubscribe, opt for a daily digest, or start a new e-group
at http://www.eGroups.com -- Free Web-based e-mail groups.

>Betty still returns upper-case when I checked a couple of weeks ago,
>but the XML-RPC spec is correct

There was a change a about a week ago. Frontier should now generate
lowercase. I say should only because I haven't looked myself.

It still accepts uppercase to keep things from breaking. This may be
removed in the future said UserLand.

Daniel


----
Read this list on the Web at http://www.makelist.com/list/xml-rpc/
To unsubscribe, email to xml-rpc-unsubscribe@...
To subscribe, email to xml-rpc-subscribe@...
--
Start a FREE E-Mail List at http://www.makelist.com !

Stewart Allen <sallen@...> writes:

> On our web site we've just started a version of the B2B Integration
> Server that is XML-RPC compatible. Attached to this message is a
> short Frontier script to test it using betty.rpc.client. Also
> attached is the WIDL file that we use to describe the interface to
> these functions. Since Frontier does not support multiple output
> values, we group all outputs into single table (struct).
>
> We would be interested to know if you experience success with this
> and other implementations of XML-RPC with B2B. To date we have only
> tested Frontier as a client.

I used the Frontier-RPC Perl module and hand testing to test with and
ran across these issues on the server side:

1) B2B returns results with an XML processing instruction that's in
uppercase `<?XML VERSION="1.0"?>', it should be in lowercase.  This
was changed just prior to the XML 1.0 Recommendation, so it was legal
before.  For reference, see the definition of `match' in Terminology
(``no case folding'') and productions 24 and 25.

Betty still returns upper-case when I checked a couple of weeks ago,
but the XML-RPC spec is correct.  Clark's `expat' treats this as a
fatal error per the XML 1.0 Recommendation but my Perl module searches
for the uppercase and replaces it with lower as a workaround.

2) B2B returns an HTTP success code and no content for several types
of errors:

     telnet www.webmethods.com 5556
     Trying 208.234.160.6...
     Connected to xml.webmethods.com.
     Escape character is '^]'.
     POST /RPC2 HTTP/1.1

     HTTP/1.0 200 OK

     Connection closed by foreign host.


Two other specific errors were a missing Content-Type and a missing
Content-Length header.

3) The response doesn't meet the XML-RPC spec:

     <?XML VERSION="1.0"?>

     <methodResponse>
       <params>
         <param>
           <name>results</name>
           <value><struct>
           <member>
             <name>MonthlyPayment</name>
             <value><string>$ 2201.29</string></value>
           </member>
           <member>
             <name>$binding</name>
             <value><string>HomeLoanOutput</string></value>
           </member></struct></value>
         </param>
       </params>
     </methodResponse>

The error is the `<name>results</name>' before the <value> inside
<param>.


The testing also showed up a bug in Frontier-RPC that I'll get fixed
and post an update: Frontier-RPC isn't specifing a Content-Type for
requests.


> Also of interest is whether or not you find the WIDL file sufficient
> in describing the RPC function signature. These first three are
> fairly simple, but a good starting point. We also have a live
> Shipping interface if anyone is interested in tracking packages from
> Frontier or other XML-RPC enabled clients.

The Frontier examples used ordered parameters for input.  From the
WIDL and the returned results, I would have expected the RPCs to
accept structs/records as input (optionally supporting ordered
parameters is a good feature, though).  I.e. for HomeLoan, I would
have expected to send a single parameter like:

     <?xml version="1.0"?>
     <methodCall>
       <methodName>Finance:HomeLoan</methodName>
       <params>
         <param>
           <value>
             <struct>
               <member>
                 <name>principal</name>
                 <value><i4>300000</i4></value>
               </member>
               <member>
                 <name>years</name>
                 <value><i4>30</i4></value>
               </member>
               <member>
                 <name>interest</name>
                 <value><i4>8</i4></value>
               </member>
             </struct>
           </value>
         </param>
       </params>
     </methodCall>

Note the lack of a `$binding' member like the output has, I don't know
how critical that would be.  Passing the above struct returns a
successful result from Finance:HomeLoan with a MonthlyPayment of $0.

--
   Ken MacLeod
   ken@...


----
Read this list on the Web at http://www.makelist.com/list/xml-rpc/
To unsubscribe, email to xml-rpc-unsubscribe@...
To subscribe, email to xml-rpc-subscribe@...
--
Start a FREE E-Mail List at http://www.makelist.com !

Sorry Ken, I'd heard that you weren't going to be upgrading Frontier-RPC
anymore. If you will, then for sure that's the best base for future development.
I'll let you (and the list) know when I have additional features to add.

Thanks.

Matt

> If it's something you think would go back into Frontier-RPC, let me
> know and I'll merge it in.  We're also working on a new upper-layer
> interface for Casbah so we can use XML-RPC side-by-side with our own
> and other protocols.
>
> What kind of things are you looking to add?




-----
Original Message: http://www.findmail.com/list/xml-rpc/?start=3
Start a FREE email list at http://www.FindMail.com/


----
Read this list on the Web at http://www.makelist.com/list/xml-rpc/
To unsubscribe, email to xml-rpc-unsubscribe@...
To subscribe, email to xml-rpc-subscribe@...
--
Start a FREE E-Mail List at http://www.makelist.com !

"Matt Daw" <mdaw@...> writes:
> To start us off... I've written a really basic PERL XML-RPC client
> that I pieced together from libwww and Ken's code. Is there anyone
> else still working in this area that would like to collaborate on a
> more robust client interface?

If it's something you think would go back into Frontier-RPC, let me
know and I'll merge it in.  We're also working on a new upper-layer
interface for Casbah so we can use XML-RPC side-by-side with our own
and other protocols.

What kind of things are you looking to add?

--
   Ken MacLeod
   ken@...


----
Read this list on the Web at http://www.makelist.com/list/xml-rpc/
To unsubscribe, email to xml-rpc-unsubscribe@...
To subscribe, email to xml-rpc-subscribe@...
--
Start a FREE E-Mail List at http://www.makelist.com !

Welcome to the new list.

To start us off... I've written a really basic PERL XML-RPC client that I
pieced together from libwww and Ken's code. Is there anyone else still working
in this area that would like to collaborate on a more robust client interface?

Matt

--


----
Read this list on the Web at http://www.makelist.com/list/xml-rpc/
To unsubscribe, email to xml-rpc-unsubscribe@...
To subscribe, email to xml-rpc-subscribe@...
--
Start a FREE E-Mail List at http://www.makelist.com !

This list provides a forum for discussing and implementing the XML-RPC
specification as a cross-platform protocol.