Following on from a recent discussion on this list [1] I've been
looking into how SCA treats directory names and class/service names.

SCA is designed to provide local PHP to PHP bindings and so there is
code in the implementation to test whether the SCA service script is
included from another script (in which case it is assumed the service
operations are going to be called directly) or whether the SCA service
script is the direct target of the call (in which case SCA swings into
action and tries to work out what sort of request it is and applies
the appropriate bindings).

1/ The conversation [1] identifies another use case where, for local
organization reasons, the SCA service script is included in another
PHP script but the intention is that the SCA service script is the
direct target of incomming requests.

2/ A second requirement from [1] is that SCA services should be able
to be defined using PEAR class naming standards, i.e. a class with the
name A_Class_Name lives in the file somedir/A/Class/Name.php

Looking at the code the solution to both of these requirements is tied
up in the way that SCA deals with service names and source file names
internally. The code primarily starts with file names but there are a
number of places where class names are guessed from file names and
file names are derived from class names.

In relation to requirement 2/ this movement backward and forward
between filename and classname poses problems as it is difficult to
determine one from another accurately given the way that the code is
layed out at the moment. Also it seems that there are quite a few
places that conversion between file name and class name take place.

It would seem sensible that we instigate a change in SCA where the
determination of file name and class name is centralized and completed
before the rest of the processing continues. In this way it seems that
we can remove some of the complexity from the code. I don't have a
detailed proposal in terms of exact code changes but I'm keen to hear
comments on this subject based on people's knowledge of the code and
why things are as they are.

Regards

Simon

[1] http://groups.google.co.uk/group/phpsoa/browse_frm/thread/3142fce2372422ef


--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to