Oh wait - now I see what you meen. I thought you just ment there was an error in the wsdl generation.
I really don't think it's a good idea to make wsdl files or jsonwsp/description files (which btw do not support this as we speak) that describe the whole collection. I think Ladon should keep the descriptions per service and try to uphold a hierarchical approach to the Collection/Service access. I would definately prefer that we make a standard collection level webservice that can list services, and maybe even service methods with arguments and types. /Jakob 2012/10/31 Jakob Simon-Gaarde <[email protected]> > Please - go ahead and fix it, no problem. > > > 2012/10/31 Mykhailo Stadnyk <[email protected]> > >> Jacob, I reviewed WSDL specification and see that you are not true. >> >> http://www.w3.org/TR/wsdl#_document-s >> >> service element defined as: >> >> <wsdl:service name="nmtoken">* ** >> >> Asterisk means the following from the same specification: >> >> "Characters are appended to elements and attributes as follows: "?" (0 or >> 1), *"*" (0 or more)*, "+" (1 or more)." >> >> So, it means that standard directly points to the fact that you can >> describe as many services as you want in one WSDL >> >> Best regards, >> Mike >> >> >> 2012/10/19 Jakob Simon-Gaarde <[email protected]> >> >>> Hi Mike. >>> >>> Simplest and least complex solution is almost always the best solution, >>> that's almost a rule in my experience :-) >>> WSDL Does not support multiple services in one description file, so when >>> you speak about imploding several services into one WSDL file I can almost >>> guess that it involves a "MetaService" that picks up all methods defined in >>> all services of a collection and wrap them into one meta service. I see >>> plenty of problems in that approach right away that tells me this is not a >>> simple nor uncomplex solution. For instance, which service class has >>> precedence if the same service method is defined in two different service >>> classes. Already here we would have to take non-intuitive choices. >>> >>> I still like the idea that it is possible to enumerate all service >>> classes and methods of a service collection programmatically, but I think >>> it should be through the approach I talked about, because it does not break >>> standards and it does not have to take undefined choices. >>> >>> Also this approach will let us keep the Ladon's URL style but now in >>> levels: >>> >>> Service-level descriptions: >>> GET http://my.domain.org/<ServiceName>/<protocol>/description >>> Service-level method calls: >>> POST http://my.domain.org/<ServiceName>/<protocol> >>> >>> Collection-level description (only one and always the same with methods >>> like "collectionInfo()", "listServices()" ) >>> GET http://my.domain.org/<protocol>/description >>> Service-level method calls: >>> POST http://my.domain.org/<protocol> >>> >>> >>> / Jakob >>> >>> >>> 2012/10/19 Mykhailo Stadnyk <[email protected]> >>> >>>> Need to check that in spec but we tried to implode several services >>>> into one WSDL and it does work! >>>> >>>> >>>> 2012/10/19 Jakob Simon-Gaarde <[email protected]> >>>> >>>>> I like the idea that the collection can describe itself. But as far as >>>>> I know there is no WSDL specification for service collections that allow >>>>> this. >>>>> >>>>> But there is nothing to stop us from exposing a single method service >>>>> at collection level which can list all services in a collection. >>>>> >>>>> / Jakob >>>>> >>>>> 2012/10/19 Mykhailo Stadnyk <[email protected]> >>>>> >>>>>> Hi Jacob. >>>>>> >>>>>> Another one idea I think IS REALLY required in ladon is to have >>>>>> WSDL/JSONWSP/etc.. descriptions for service catalogs. I mean if there is >>>>>> published subset of service objects it's good to have only one URL which >>>>>> describes all the services available. >>>>>> >>>>>> Than just in client: >>>>>> >>>>>> import suds >>>>>> service = suds.client.Client(' >>>>>> http://localhost/soap/description').service >>>>>> service['Test'].echo() >>>>>> >>>>>> Because currently if I want to work with several service objects I >>>>>> need to do 1 more HTTP request to parse description for each service I >>>>>> use >>>>>> and it's not very good. >>>>>> >>>>>> I guess it's not hard to implement. Currently I'm working on REST >>>>>> implementation proposal and after I guess I can work on this feature. >>>>>> What is your opinion? >>>>>> >>>>>> Best regards, >>>>>> Mike >>>>>> >>>>>> -- >>>>>> Mailing list: https://launchpad.net/~ladon-dev-team >>>>>> Post to : [email protected] >>>>>> Unsubscribe : https://launchpad.net/~ladon-dev-team >>>>>> More help : https://help.launchpad.net/ListHelp >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Med venlig hilsen / Best regards >>>>> Jakob Simon-Gaarde >>>>> >>>>> -- >>>>> Mailing list: https://launchpad.net/~ladon-dev-team >>>>> Post to : [email protected] >>>>> Unsubscribe : https://launchpad.net/~ladon-dev-team >>>>> More help : https://help.launchpad.net/ListHelp >>>>> >>>>> >>>> >>> >>> >>> -- >>> Med venlig hilsen / Best regards >>> Jakob Simon-Gaarde >>> >> >> > > > -- > Med venlig hilsen / Best regards > Jakob Simon-Gaarde > -- Med venlig hilsen / Best regards Jakob Simon-Gaarde
-- Mailing list: https://launchpad.net/~ladon-dev-team Post to : [email protected] Unsubscribe : https://launchpad.net/~ladon-dev-team More help : https://help.launchpad.net/ListHelp
