Hi Graham
Some more comments in line...
On 31 Aug, 11:26, Graham Charters <[EMAIL PROTECTED]> wrote:
> Hi Simon, thanks for the rapid comments. Here's my thoughts on the
> two issues you identified:
>
> > 1/ What should SCA do if it finds a method without annotations, i.e.
> > no type information
>
> This probably depends on the type of service. Service types which
> don't have a service description (e.g. local, REST and Atom), don't
> require this information to be specified. Service types which do have
> service descriptions (soap, json-rpc, xml-rpc), do (to varying
> degrees).
>
> I think if the binding type requires documentation then we should warn
> and not generate (rather than generating something which is of no
> use). If the binding type doesn't require documentation then it's
> included.
>
> > 2/ How can methods be omitted from the service interface, i.e. we just
> > don't want to expose the method
>
> I don't think the absence of comments should be used as a control
> mechanism for the reason you and Matt have already highlighted (might
> want to document something but still not have it on the service
> interface).
>
> I quite like the idea of using interfaces to add this level of
> control. It would also be consistent with SCA (SCA Java does this and
> also supports the same class implementation approach we use (i.e.
> where there is no interface)). How about something like:
>
> /**
> * Scaffold implementation for a remote StockQuote Web service.
> *
> * @service StockQuoteInterface
> * @binding.soap
> *
> */
> StockQuoteImpl implements StockQuoteInterface, ANOtherInterface {
> ...
>
> }
So I like @service StokeQuoteInterface
If you are suggesting that we can parse the StockQuoteInterface to
pull out the method names which should be provided as service
interfaces (without the need for further annotation on the interface
itself) then this could work. My approach was a contraction of this by
just providing the method names after the interface name in the
annotation but your approach is more forward thinking.
Presumably the default would be to provide all methods if no interface
is described.
>
> This would be taken to mean that only those methods defined on
> StockQuoteInterface are part of the soap service. Those in
> ANOtherInterface or just in StockQuoteImpl would be excluded. I'd
> prefer to pursue this approach rather than creating a new annotations
> which may go away in the near future.
>
> Does this make sense and seem sensible?
>
> On 31 Aug, 09:30, [EMAIL PROTECTED] wrote:
>
> > On 31 Aug, 08:42, Graham Charters <[EMAIL PROTECTED]> wrote:
>
> > > Pecl Request #11944 (http://pecl.php.net/bugs/bug.php?id=11944) is
> > > asking for finer-grained control over the methods which are surfaced
> > > on a service interface. We currently just use class visibility (i.e.
> > > all public methods) to control this.
>
> > > There's a small amount of discussion in the request, but I thought it
> > > would be good to raise it here to get greater visibility and gather
> > > more options/opinions.
>
> > > Graham.
>
> > Following up on the comments made in the feature request...
>
> > It is true that in the Java SCA implementation the @Service
> > information is associated with interfaces so a class will implementat
> > one, or more, interfaces and this tells the runtime which methods of
> > the class should be treated as service methods.
>
> > This is not currently how the PHP SCA implementation works. All
> > annotations are placed on the class itself. This leads to a level of
> > simplicity in service construction but we pay for this in lack of
> > flexibility, for example, in excluding some methods from the service
> > interface. At least given the set of annotations we have at the
> > moment.
>
> > Having said this I'm not convinced that the use of unannotated (is
> > that a word?) methods as part of the service interface makes a lot of
> > sense give the way that the implementation works at the moment. If you
> > look at what is actually generated in the WSDL in the case of the
> > method "function foo($bar)" in the feature request it doesn't seem to
> > be that useful. I.e. it defines null input and output types. I assume
> > this is because there are no annotations for SCA to use for typing the
> > interface. Fine for PHP but not so great for a service interface.
>
> > So there are two issues here
>
> > 1/ What should SCA do if it finds a method without annotations, i.e.
> > no type information
> > 2/ How can methods be omitted from the service interface, i.e. we just
> > don't want to expose the method
>
> > As first suggested we could omit methods that don't have comments at
> > all.. However this is problematic for issue 2 as annotations may have
> > been included for producing the documentation that the annotations
> > were originally designed for. However I think we should consider
> > omitting methods without annotations due to issue 1 so this could be a
> > short term solution 2.
>
> > Following the conversation on for issue 2. Maybe, as an alternative to
> > @scaExcludeMethod we could defined some new annotation for the header
> > block that works as an alternative to defining an interface (we should
> > look whether interfaces could be made to work), e.g.
>
> > /**
> > * Scaffold implementation for a remote StockQuote Web service.
> > *
> > * @service
> > * @serviceinterface GetQuote getQuote
> > * @binding.soap
> > *
> > */
>
> > If these don't appear then the default would be to operate as now
> > with all of the (annotated) methods being parsed. The intention here
> > being to replace/augment this with annotations on interfaces if/'when
> > they work.
>
> > Regards
>
> > Simon
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"phpsoa" group.
To post to this group, send email to phpsoa@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---
