HN Explorer

12 comments

[ 0.20 ms ] story [ 72.7 ms ] thread
bouke
Author here, happy to answer any questions.
drmohundro
This looks great - I was working with an old iOS app back when Swift was first released and I wrote an XML parsing library SOLELY because the SOAP support was horrific. I think this will help a lot of people. If you don't mind, I might add a link to your repo from my README just to help point people towards a better approach over manual XML parsing.
bouke
Thank you! links are fine of-course; the more the merrier.
joelhaasnoot
I pitty anyone writing direct SOAP interfaces for an iOS app.

From a few years of app dev, at the end of the day it makes everthing a lot more flexible if proxied, even with a tiny facade, because it gives you options and choices when it comes to making changes.

troels
Good point. Wouldn't you usually do this on a server and then expose a sane api to the ios app? Who consumes SOAP directly in ios?
bouke
Sure it might not make sense to use SOAP for communication between an iOS app and its server-side counterpart. However when writing consumers of an existing SOAP service, for example in an macOS or console application; it might make more sense.
spdustin 

    Why is it called Lark?

    SOAP is sometimes referred to as a fat messaging protocol.
    Swift is an elegant bird. 
    A Lark sometimes looks like a fat bird.
Excellent sense of humor, and a really useful library. Thanks a bunch for sharing!
mvantellingen
Cool! As the author of a relative new python soap client (zeep) i do feel sorry for you Most wsdl documents dont follow the various specs which will result in a lot of support issues from users

Anyway feel free to contact me if you have any spec related questions

bouke
Cool project, seems like a nice improvement over what I've used in the past (suds). Also has some features that Lark currently lacks (SOAP 1.2 / HTTP bindings / rpc / WS-Addressing / WSSE).