==Topic== {{TOC}} ===Status=== * Some experiment with egs and weberp, starting with debtorsmaster table for integration. * There is also some activity for integrating POS systems with nusoap interfacing. ===Goal=== Getting confirmed if this it the right architecture (webservices) and tool for integration other software with WebERP. ===Description=== ===Implementation Options=== ===Advantages=== ===Disadvantages=== ===Planning=== ===Discussion developers list=== The only thing I've had against Soap was that it was a little bulkier - though also more structured, I believe, than xml-rpc. Essentially, as the last link you sent points out, they are both xml based protocols. You are correct that if we really intend on allowing interoprability with other systems, Soap is the more standard choice. One thought regarding this is whether we should consider using the least common denominator since it should be easier to make and xml-rpc based system step up to soap (or be wrapped with something like nusoap) than the other way around, or simply say "soap is what we're using, deal with it". I think we all realize alot of specs, functional requirements, etc need to be ironed out before any of this has any real meaning. It would be ignorant of us to build the foundation without a firm grasp of what it actually will need to support. good discussion, thanks. -----Original Message----- nusoap looks really simple. Please study http://www.zend.com/zend/tut/tutorial-campbell.php I guess that you are right that xml-rpc is easier to implement but I think that soap already has the biggest market share to be the standard for now and the future. When this statement is true, then is soap a better garantee that we serve more applications which want to be integrated with weberp. But I would already be glad when one of them will be used to integrate other applications, because it is much better then mission impossible moving everything to the same programming language and the same database engine and write for every case different code. I guess that your xml-rpc is described at: http://xmlrpc-c.sourceforge.net/xmlrpc-howto/xmlrpc-howto-soap.html ----- Original Message ----- Thanks. Soap actually worries me more than more simple implementations like xml-rpc. I've had many thoughts on various ways these things can be useful, but not the time to sit down and really flesh them out. Hopefully I can do that soon. -----Original Message----- The wddx and xml is a very interesting subject. There are plans to setup a demo with nusoap for webERP, EGS, XCRMS and eventually oscommerce. The current integrated fork of weberp and egs might be a leading role how to implement the nusoap solution. That will save us design time for the demo. For me would be the first step to integrate the debtormasters address data with the help of nusoap. The idea is to create one nusoap layer for weberp wich enables to integrate smoothly a crm application of someones choice without changing the nusoap layer. In this demo, we should be able to choose between xcrms and egs. When this is a success, then I guess that it would be very interesting to integrate oscommerce with weberp and one of the crm applications. An example of nusoap is: http://www.zend.com/zend/tut/tutorial-campbell.php It really looks like very simple. After the demo we can evaluate it and start any discussion for contributing the nusoap concept to weberp. I really think that it is a concept which will saves us lot's of development and support time for integration with other software packages. Or do you have another opinion about this? Some do not like xml, because it is technically not very efficient but for me is the development speed also very important when we needs sometime to be competing with SAP, peoplesoft, .... ----- Original Message ----- I have thought about this, my reasoning for going against the wddx for implimenting database configuration storage is that we are already agreed that we would like to do some XML data exchange with other applications (at least thats how it seems to me). To this end we should probably have a standard for exchanging data (of any part of the system) with at least a Low and High level api. To make things easier when we get to such a definition of api I decided to use standard database tables/fields where possible. This would allow for any type of api, including working/reporting directly against the database. ( I will create some libs for FreePascal and C/C++ and Python against that api) I feel we need to do some planning before we implement the api. I know I suggested the wddx, because I want to have a easy interface to data, however in the long run we could probably do more not using wddx in the core where we don't have to. I do like wddx as an data exchange medium though, as long as it's well thought through; Nothing sucks more than a bad xml implementation. It would still be hard for the user to edit xml (errors could bring the system down) and therefore script interfaces to edit the data need to be created, which I am doing. So why not keep the underlying system in tact and working the same way the system does now. Almost the same amount of work is required either way, at least this way we are not preempting the api. I will make a concession though, I will use xml/wddx for storing the arrays because a hash list (key/value pair array) is easier to store that way, its a very readable/editable format (in db directly), but a flag will indicate that it is stored in that format. I might be wrong in that there might be some easier way still. I am trying to limit the hits to the database to just one query and then storing static type config data in the session to limit the data being queried. Data that is liked into tables will however reside in seperate tables, mostly for refferencial reasons where reporting is concerned. I think the api stuff should come after version 3 (going on thoughts previously mentioned here in the list), also I need to think quite a bit more on what I want to do with the api and I am sure the whole team has their own requirements too. The wiki is probably the best place to just get a roadmap going for what we want in an api, something like a suggestions page for functionality. And then there is Phil "the voice of reason" (said with appreciation) who will keep us focused. ----------Original Message--------------------------------- You are correct that we should be able to un/serialize with any db - basically all it would do is store text in a db field - that is the same way wddx would work if that's all we were concerned with. The advantage of something like wddx would be in passing serialized versions of data between various programming languages or between applications/webservices/processes/etc. It goes a step further than XML, though, in that they are providing an SDK for the functions that are used to go from wddx to native language data structures and vice-versa, which would remove some of the complexities that would be involved in doing that with XML (dom parsers, xsds, xsls, etc. depending on how anal/code generator dependant the user is - and I'm not taking shots at anyone, I've done both). A review of their faq would probably bring out many other things and explain the things above further: http://www.openwddx.org/faq/. ----- Original Message ----- un/serialize & wddx both encode data and both encode it into what are essentially strings. Since wddx is xml based, it is generally more readable and probably creates a larger 'data footprint' when it encodes, though none of that is really applicable. The transport mechanism is also not wholly important it could be via files in the filesystem, sql dbs, server-to-server communication, etc. The real differences here can be realized by looking at how you are able to work with these strings from various languages. Simply put, unless someone has built/builds un/serialize functions for several other languages, those strings are going to be fairly useless in other languages. On the other hand, wddx has libraries for its functions available for many popular languages (javascript, php, m$ stuff, more...). For it's part, un/serialize can handle php objects, which wddx can not help you with. In regards to anything we are currently discussing, especially this config system, I think wddx would be out of place for many reasons (complexity, db integrity). I see from Danie's recent message that he has settled on some similar way of approaching wddx and the immediate task. ----- Original Message ----- I have not used serialize or wddx and don't currently have time to dig into it too far or try a bunch of it out. I think it's great that wddx takes care of the xml layer for you on the way in and the way out. However, I'm under the impression that serialize encodes the data structure in the "same" way wddx would. Maybe that's where the difference lies. While serialize would use an internal representation, xml will put it in a form (text really) ready for easy transport and use in other applications no matter what they are written in and where they are, using web transportation. Am I getting it? parsers, xsds, xsls, etc. depending on how anal/code generator dependant the user is - and I'm not taking shots at anyone, I've done both). A review of their faq would probably bring out many other things and explain the things above further: http://www.openwddx.org/faq/. -----Original Message----- What is the advantage of storing complex variables by wrapping in xml using wddx as opposed to just using serialize and unserialize? I think we can store and retrieve arrays, etc. using serialize in all databases...