Title: [Ldsoss] Cool Family History technology coming soon - SOAP v. RESTv. XMLRPC Continued
PhpGedView version 4.0 will include a SOAP web service.  See
There is still work to do on this API, such as adding family and source complex types but at this point it is a good replacement for the older REST style web service.
 
I would agree that SOAP web services are more widely used today than XMLRPC and are probably a better choice for new development.  Most languages now have libraries available that reduce SOAP to something like a DLL or a class that you can call methods on without knowing much about the SOAP behind it.
 
--John
 
John Finlay
PhpGedView Project Manager


From: [EMAIL PROTECTED] on behalf of Dave Wagner
Sent: Sat 10/22/2005 4:24 PM
To: LDS Open Source Software
Subject: [Ldsoss] Cool Family History technology coming soon - SOAP v. RESTv. XMLRPC Continued

I will not pretend that I know a lot about any of these options however,
what I do like about SOAP is the ability to be handed data in a specific
type, e.g. string, int, datetime, etc. I suppose, although I don't know
for sure as there aren't very many WS providers that offer XMLRPC (at
least for the types of things I've looked into), that XMLRPC would
provide type support being that it is still XML.

I think that calling one easier than the other is kind of a relative
thing, I mean it really depends on what you need to do with the
information and which platform/language your consuming it with. I prefer
SOAP mostly because I develop for windows using .NET. I can reference a
SOAP WS and consume it just as easily as any DLL. To me, this is much
easier than trying to consume data from an implementation of phpGedView
[1]. In order for me to do that I would have to write a class that
passes arguments through one long string and returns the data (holding
session information as well). Then I would have to write another class
to parse out every possible combination of returned data, which gets
very tedious when there are complex relationships with the data (as is
usual with genealogy). I know this because about a half a year ago I got
about 50% done with a winforms interface to phpGedView [1] when my hard
drive crashed, I honestly did not want to do all that again.

I know what you mean about paypal though. I'm currently creating a
rather large data mining application for my company and am being pained
all the way by Paypal's API. It was simply not well thought out.
Creating several custom complex types just to return all data as a
string (with the exception of some datetime values) is just annoying.

Dave

[1] http://phpgedview.sourceforge.net/


Richard Pyne wrote:
> On 13 Oct 2005 at 18:26, Mac Newbold wrote:
>
>  
>> Today at 7:57pm, Dave Wagner said:
>>
>>    
>>> Let me push my luck and suggest that SOAP be presented as the
>>> primary means of exposing the churches content. XMLRPC and REST
>>> are just annoying IMHO (REST especially).
>>>      
>> As long as we're presenting suggestions, I suggest allowing both
>> SOAP and REST/XMLRPC. I find SOAP annoying, because I think it is
>> too big and bloated and complicated. People (especially
>> developers) like "simple" as long as it meets their needs, and
>> only go complex when necessary.
>>    
>
> Amen to the "simple", but I'm not sure I would call SOAP simple,
> but I think it could be.
>
> I recently finished a project for work interfacing with a
> service (PayPal Website Payments Pro) that could have been done
> in less than a day using name=value pairs, less than a week
> using XML, but took 2 months using SOAP. I will admit that this
> was my first project using SOAP and could have been much simpler
> even using SOAP had the wsdl and xsd been trimmed down to only
> what was needed instead of encompassing every minute piece of
> data that the service provider has availble in every service it
> offers (eBay). My experience has been that protocols and
> standards that start with the word "Simple" seldom are.
>
> --Richard
> _______________________________________________
> Ldsoss mailing list
> [email protected]
> http://lists.ldsoss.org/mailman/listinfo/ldsoss
>
>  

_______________________________________________
Ldsoss mailing list
[email protected]
http://lists.ldsoss.org/mailman/listinfo/ldsoss

_______________________________________________
Ldsoss mailing list
[email protected]
http://lists.ldsoss.org/mailman/listinfo/ldsoss

Reply via email to