Re: [PEPr] Call for votes on Web Services::Services_Webservice

weber@mayflower.de wrote:

3. Extending the Webservices_Webservice class is not good and too restrictive. You should should use a decorator pattern that would accept a class name or an instance of it on which you run the reflection functions, and use the __call() PHP5 feature to pass the queries.

Extending Webservice is too restrictive? Decorator pattern? Passing instance? I better not start a discussion about that!

class a { } class b extend a { } then how do you expose class b as a webservice??? Extending Services_WebService is just plain bad design.

no it is not. it is not plain bad design like you said. it is the general way you do create webservices in other programming languages.

That argument has never been very useful to the PEAR community. PHP is a language of its own, and comparing it to other languages for certain implementations doesn't necessarly work. Does it mean that because PHP doesn't support multiple inheritance that PHP is no good?

If you do webservices that mainly interact with other programming languages like java,.net,delphi than you should bring some continuity to the users. thats why webservices should work similair. Yes, webservices must *behave* in similar ways so they all comply to the same *communication* protocol and understand each other. To the other end point it shouldn't matter if the webservice is written in Java, .Net... PHP. If you want to write your webservice in C, then don't tell me that I *have* to extend a certain class that can't exist due to the language constraint.

you do not create a webservice from many classes but from ONE class!

Right, and still you didn't answer me on how to expose class b above as a webservice using your solution... and of course extending "class a" to be sub-class of Services_WebService is not one.

you do not expose class b as a webservice. you do expose class a as a webservice. class b as another webservice if you want. No, I may not want to expose "class a". "class a" could simply be a base class also extended by other classes in a broader application. This is where your designed is flawed. Your design is mandating something that is not required to fulfill the purpose of the class.

Sure you can always slap a wrapper around "class b", and pass that new class to be exposed, but then the coders will need to put in place all the hooks. And they will have to do so *over and over again* for each class they may want to expose as web service. This is not good. The smart way to go is to let the package do that. It gives more freedom to the users.

but say you create a webservice from class a that contains a reference to class b than class b is considered as a complex type. that is the way it is working. ...with your implementation.

creating a webservice from class a means that all public functions except the contructor and desctructor are seen as public operations. creating a sevice from "class b" means exposing all public functions from "class b" therefore exposing all functions from "class a".

all other depending classes are only public properties. Why should they be?

the methods in depending classes are irrelevant for the webservice.

depending classes are considered as types within that class. So before we continue here i would propose you get some experience how that in general works. see what i really dont like and dont understand is how someone can come up with sentences like "that is plain bad design" without being informed enough.

It's a bit presumptious for you to assume so. I am not questioning the usefulness of the package, but it's too narrow implementation. If your package is not subject to reviews or suggestions, why bother submitting it to PEAR?

I don`t know. The package is usefull, becauses generating WSDL from hand is really a pain. But see, there are far bigger issues to solve the stuff you came up with. for. example : 1) Do all clients work with the wsdl? Some clients cannot generate a proxy client when the wsdl-complex types are not parsed in the correct order. 2) The Package name 3) ... the differences between .net and php is that ms modules nowadays are completely soap based, where php also works with rpc. The thing is .. I spent nights over nights finding a way to creating wsdl that work with every client. And your work is appreciated.

I am thankful for everyone looking at it but I don`t like someone coming up and giving me orders. Sometimes a simple "What do you think about this?" is a better way to start a discussion. Ok, sorry, maybe I came a bit strong on you. It's just that alarms went off when reviewing your code.

4. There is certainly a way to get some work with the upcoming XML_RPC2. Maybe the XML_RPC2_Server should be spun into some kind of XMLRPC profile to a generic WebService_Server package.

That is right.

We don't want to duplicate efforts to implement reflection, docblock parsing and so on for each different webservice protocol.

Who do you mean with "We" ? You are probably right. But like things are going here in Pear this wouldn`t lead to any result.

"we" = community of PEAR developer at large. It's not because there are heated discussions some times that they don't end up good. It would result in a better design (see recent discussion around XML_RPC2 and XML_RPC2_Value_* classes)

As is, I would probably vote a -1. But will hold my vote for now, to see how things are going first.

Is up to you!

5. For the "info" method, use standard HTML and not <div style="font-size: 36px"> type of things... An <h1> would have done just fine.

Yes, but I can also use <div>

Yes, you can, but then you are making it impossible to easily apply CSS. Standard tags exist, so use them. It makes life easier.

the infopage does not exist to be changed from any user. it gives information about the webservice. so why discus this now?

Because it is part of the review process... The best option would be of course to use some kind of template. The next best one is to use standard HTML tags so applying a CSS would be easier.. I can easily imagine that users of this package would want to integrate a call to the info page in their website well preserving their look and feel, or at least staying close to it. To do so, they could simply add a "<link>" tag in your package source. Also what about small screen devices that would be hard pressed to display "font-size: 36pt" or whatever you decide is the right choce. Using standard tags is the most effective way to do things, because their are *standard*. OK, that is an argument I accept. I will change this.

Please, if you want to do CodeReview then better prepare a little bit more. You cannot pass class-instances for Reflection. Do imagine where this would end up?

I'll just say: $instance->get_class() Passing an instance is not only for convenience, you may want to prepare your service instance before exposing it and accepting requests...

you do not create instances when generating wsdl.

Agreed, but I'm seeing a larger scope where your package could be the dispatcher of requests for various webservice protocols. As a last work, please have a look at XML_RPC2.

-Philippe