I may reply to John's very detailed post later, particularly focusing on areas where the application is limited by HTTP at the moment (and hence some skepticism as to whether the whole application should be exportable as web services) but for now I have three questions:
1) What is the scope we want to give to the web service interface? 2) How many of these areas would the database-level API structure we are working on be a better or worse fit? 3) As far as state handling, do we really need "stateful web services" or should we look at a re-usable API which could be encasulated over other protocols (for example XMPP) where we need a richer interface/things like state handling? I will say clearly that in an ideal world, everything in LedgerSMB would be running over a fully stateful protocol, but that's not a model we have inherited and so we do a lot of work in some areas getting around the fact that we are using the adjustable wrench that HTTP is to pound nails. Best Wishes, Chris Travers ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d _______________________________________________ Ledger-smb-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
