Re: receive xml

On Nov 20, 7:26 pm, "Peter H. Coffin" <hell...@xxxxxxxxxxxxx> wrote:
On Fri, 20 Nov 2009 13:07:21 -0800 (PST), Dave wrote:
On Nov 20, 3:33 pm, "Peter H. Coffin" <hell...@xxxxxxxxxxxxx> wrote:
On Fri, 20 Nov 2009 15:16:54 -0500, Jerry Stuckle wrote:
Dave wrote:

So there is no way to strictly communicate with XML using PHP and
cURL?

Not through the HTTP protocol. That's the restriction, not PHP or
cURL.

As close as one could kind of come is to stick the whole XML document
into a single element of a POST, but that's only ADDING complexity, not
making it easier.

--
12. One of my advisors will be an average five-year-old child. Any
   flaws in my plan that he is able to spot will be corrected before
   implementation.
        --Peter Anspach's list of things to do as an Evil Overlord

Correct.  I could have implemented that easily based on the tools
provided in PHP.  Leave it to me to add complexity.  :)

It happens. Usually when we're not looking.

Could I accomplish this task with fsock*, fputs, and fgets?  

Sure. And if you want to go the pure XML route, that's a very viable
option, even with PHP. You can write daemons in PHP. It may be more work
than a POST, but then you've got a daemon that can accept requests from
other processes than browsers running Javascript too.

I guess what I'm trying to duplicate is how JavaScript can do an AJAX
call (HTTP GET) and process the XML when it returns using built-in
functions of the coding language on the client. I am trying to make
my project as open to as many other lanaguages/OS's/applications as
possible. At this point, the client will already have to communicate
using HTTP GET, so am I making things easier by now making them accept
pure XML or should I just remain uniform by only using HTTP GET/POST?
Are there advantages of one over the other?


Does it
make sense to use pure XML over an HTTP POST and stuffing the xml in a
variable?  Wouldn't this make it more universal?

Well, the obvious thing is that the POST mechanism already has all the
parseing work done for you, so there's several steps already taken care
of. If you really have a complex structure that includes many different
kinds of parts that occur 0 or more times, then doing exactly that might
be worth it.

--
When C++ is your hammer, everything looks like a thumb.
              -- Steven M. Haflich

When coding the client/server side, all the communication will entail
is just sending the XML data. I will rely on the built-in functions
of the programming language on the client side to parse the XML data
and since the server is just sending it to the client, there isn't any
parsing to be done there. I think this is a very basic setup overall.

I would appreciate anyone's comments on a better way to handle this
versus the way I am attempting to do it. I would much rather have a
solid way of communicating than not. Here is an overview of the steps
needed (four step process called CASA) which will be opened up to the
public in the form of an API (around 1/1/2010):

(c)ontact - our server contacts the client and requests their SID as
authentication
(a)uthenticate - the clients servers return their SID as text
(s)ync - we give them data (XML) to syncronize their database with
ours
(a)ccept - the client creates an MD5 hash based on the data (XML)
received and sends that hash back to us to compare the data sent
versus what they received

I think the steps above are a good way to make sure the client is who
they say they are as well as data integrity checking on both ends
(plus it will all be done using SSL for security). Note that the
first two steps are actually handled as one HTTP GET request/reply.
The third and fourth steps are what I am currently contemplating.

Dave
.

Relevant Pages

  • Re: receive xml
    ... Not through the HTTP protocol. ... As close as one could kind of come is to stick the whole XML document ... provided in PHP. ... the client will already have to communicate ...
    (comp.lang.php)
  • Re: receive xml
    ... of the programming language on the client side to parse the XML data ... and since the server is just sending it to the client, ... client" may not be feasible with http. ... I'm not fixed on sending straight XML in the last ...
    (comp.lang.php)
  • Re: HTML and XML
    ... XML over HTTP can be used to simply convey text content or metadata or it can be used to convey rpc commands - it depends on what you want to define as the execution engine. ... Think about ODBC - that's plumbing that does not specify that you should do server to server or client to server. ...
    (comp.databases.ms-access)
  • Re: OT: squid-type cache for XML?
    ... I am working on a project where a 'client' periodically queries a number ... of 'servers'. ... The exchanges are done using XML. ... Proxies like squid work on the protocol level (HTTP) - they do not care what ...
    (alt.html)
  • [UNIX] Alteon ACEdirector Signature/Security Bug
    ... A new security bug has been discovered in the Nortel Alteon ACEdirector ... HTTP clients could exploit it to determine the IP addresses of ostensibly ... "hidden" web servers that are load-balanced by the ACEdirector. ... uses it to persistently map a series of HTTP client requests to the same ...
    (Securiteam)