Develop XCube_Service (2/2)

Next problem is the possibility that inner web service and outer web service may be different. That's an important problem. XCube_Service has the feature that removes the difference of inner service and outer service. But, what we will do if developers doesn't want it...? Inner XCube service may be requested to include no content of outer sites.

If service class is easy to write, that's no problem. Preparing two kinds of classes might be good solution. But, regrettably, service class demands strict definition to developers. Therefore, that isn't easy to write quickly. Perhaps, XoopsObjectHandler is more excellent mechanism to relay contents of modules contents than service class. Of course, it's possible to abstract a handler for connecting web services. The design of XoopsObjectHandler is very good at that point.

But, abstract layer to web services is important very much at this times. Just relaying contents of other modules isn't important. In that case, XOOPS Cube will be requested to connect other sites in the near future. It's ideal that relaying contents to both other modules and other sites is realized by writing just one class.

Most developers might not use both XoopsObjectHandler and XCube_Service. But, it's possible to add XCube_Service to a module by other modules or 1 File Hacking. We have to clear up the purpose of the class. That makes the code of the class simple. As you are aware, we are working on beta sequence that is shown at Roadmap. By some complex causal association, we have to do parallel development that is brushing up code and re-designing XCube namespace. XShade and exReview are good test.