Re: receive xml

Dave wrote:
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?


Not at all easy to do. Non-web related languages such as C/C++, SmallTalk, COBOL, etc. generally do not have built-in support for http. You can get libraries for some of those languages, but not all.

It really looks to me like you are trying to be too much to too many things. The result is always you are too little to everyone.

Define your target audience. "The whole world" is NOT a good target. Then write for that target. The more specific the target, the better.

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


--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@xxxxxxxxxxxxx
==================
.

Relevant Pages

  • Re: receive xml
    ... into a single element of a POST, but that's only ADDING complexity, not ... And if you want to go the pure XML route, ... the client will already have to communicate ... using HTTP GET, so am I making things easier by now making them accept ...
    (comp.lang.php)
  • Re: [PHP] Calling PHP functions from within javascript
    ... First of all PHP is server-side and has nothing to do with client side. ... of ekstra files through XML modules very flexible and easy. ... a webstore sollution I have developed has an interactive menu ...
    (php.general)
  • Re: receive xml
    ... cURL? ... Not through the HTTP protocol. ... As close as one could kind of come is to stick the whole XML document ... provided in PHP. ...
    (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: HTTP POST problem
    ... client application is lightweight. ... Is there any way I can be able to access http raw data or correct ... binary files. ... PHP Classes - Free ready to use OOP components written in PHP ...
    (comp.lang.php)