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. > the webservice class is the endpoint. if you want to extend it you have to call it as a webservice. >>>>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. > I can understand that. The package has exactly the same behaviour like asp webservices. But class_a is the endpoint and one should for security reasons take care with functions he wants to offer as a webservice. he might loose control when creating webservices recursively. also the wsdl-file filsize would then increase enormously when all depending types are included. I think this concept is quite well considered from ms. I really don`t want to change this. >>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. > yep within this implementation and within .net implementations and I am quite sure that delphi does it the same way. And I don`t see why that does not make sense. >>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? > Depending classes are just kind of type wrappers. Nothing more. (Within this implementation and within .net implementations) >> 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 > > Manfred