On Fri, 22 May 2015 at 17:27 Jeffry Killen <jekillen@xxxxxxxxxxx> wrote: > > On May 22, 2015, at 3:53 AM, Stuart Dallas wrote: > > > On Fri, 22 May 2015 at 07:20 Jeffry Killen <jekillen@xxxxxxxxxxx> > > wrote: > > This may be a bit off topic but I begin with understanding of > > php and doing synchronous and async queries generated by > > javascript on the client side. > > > > Recently I resurrected a home built server and installed FreeBSD. > > Since I have been doing probably as much javascript as php, I have > > been interested in exploring node.js. > > > > My question is academic > > > > How is a simple query from a client like Firefox to an http server > > using > > php to process the request different from RPC? > > (I have been looking at Wikipedia article on RPC: > http://en.wikipedia.org/wiki/Remote_procedure_call) > > > > I have written call back functions that are invoke from a window > > opened > > in javascript that call functions in the opening window. And as well, > > calling > > a server side script generally involves calling functions and methods > > and > > sending a result back to the client. > > > > For instance, there may be a form that is used to compose and > > execute a > > query of the server's data base server (MySQL, Postgres, etc) and the > > result is assembled and sent back to the client for display. > > > > How is this different from formal RPC? > > > > Now there is Apache Thrift with bindings to node.js (and other > > languages), > > which seems to imply that php can hand off requests to a node.js > > server, > > that might in turn satisfy a client request. (node.js is server side > > javascript) > > > > Right now I wouldn't do anything outside of localhost with node.js > > because > > it looks like asking for a whole lot of trouble if used over public > > network. > > > > Are there any academic thoughts on this? > > > > Generally speaking, RPC (as a concept) is simply "making a request > > to a remote server and receiving the results." The term originated > > with distributed systems with technologies such as CORBA. > > Essentially RPC describes the format of the request before it hits > > the transport mechanism (HTTP, 0MQ, TCP, whatever), and there are > > several different standards. XMLRPC is another technology that does > > RPC defined using XML over HTTP: http://en.wikipedia.org/wiki/XML-RPC. > > > > The main distinguishing feature of an RPC against simply using, for > > example, a REST service is that the client does not necessarily know > > that it's calling a remote procedure. That fact is hidden by a class > > or library that wraps the remote call in a local function. > > > > Doing RPC over public networks is acceptable so long as you use SSL > > to protect the data and authentication to prevent unauthorised > > access. This is generally not a bad idea even within a private > > network, because there really is no such thing as a private network! > > > > I hope that helps expand on what RPC is and why it's different from > > submitting a form on a web page. > > So, the class or library would be local to but separate from the > client itself? > Local as in it's just another class that the application uses, yes. It's separate depending on what you mean by separate. In the interests of making it reusable for other projects I'd recommend it be a library that your application uses rather than a part of the application itself. As if, say, javascript had to call a function in another application > to make an > async request to a server. This is a bit subtile for me. It appears to > be another > layer between the application layer and the transport layer. > The point is that the Javascript application doesn't know it's making a request to another server - it's all wrapped up in the library as an abstraction layer. It may seem subtle to you, but that's the whole point. Once you have that layer of abstraction you can change other services in any way you want without causing huge ripples, so long as you keep to the same API for the library. -Stuart -- Stuart Dallas 3ft9 Ltd http://3ft9.com/
