You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@axis.apache.org by Nabeel Yoosuf <na...@gmail.com> on 2006/06/04 16:32:25 UTC
[Axis2] PHP XML IN-OUT Message Receiver
PHP XML IN-OUT Message Receiver
-------------------------------------------------------
This message receiver allows you to write your web services implementation
in PHP and expose it through Axis2/C engine.
It uses PHP embed SAPI to call PHP code from C.
The README file gives some details about the receiver and how to install it.
There are two examples shipped with this. echo and math services. Drop them
into services folder and you can call it from any client!
I think this should go to a folder called "contributions" inside Axis2/C
SVN. (c/contributions/php_xml_msg_recv/)
-Nabeel
[Axis2] make dist issues
Posted by Samisa Abeysinghe <sa...@gmail.com>.
There are some issues with make dist as well:
1. running ./configure fails with error "config.status: error: cannot
find input file: test/core/clientapi/Makefile.in"
2. platforms headers are missing in include
3. util is missing
4. axiom is missing
5. xml_schema is missing
6. woden is missing
7. docs are missing
Please help fix this.
Thanks,
Samisa...
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
Re: [Axis2] make bindist issues
Posted by Samisa Abeysinghe <sa...@gmail.com>.
Samisa Abeysinghe wrote:
> make bindist
> 1. the resulting file is axis2c-bin-0.92-linux.tar.gz, but this is in
> tar format, not zipped
> 2. docs are missing in the bin extract
> 3. .la files are present in lib folder of extract. Can we drop them?
> 4. xml_schema header files are missing in include
> 5. woden header files are missing in include
> 6. .a files and .la files are present in services sub folders. Can we
> get rid of them?
> 7. current log files that are present at the time of running 'make
> bindist' are packed into the log folder. We should not copy these old
> log files in to dist
> 8. an FSF INSTALL file is copied into the samples INSTALL file. This
> is *very* wrong.
> 9. can we link the README, ChangeLog, INSTALL, NEWS and COPYING files
> in the samples folder to those in the root dist folder?
> 10. running ./configure in samples folder fails with the error:
> "config.status: error: cannot find input file: client/Makefile.in"
>
Some more:
11. rampart module bin is missing
12. rampart sample is missing
13. xml schema sample missing
14. woden sample missing
Samisa...
> Please help fix these.
> Thanks,
> Samisa...
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
[Axis2] make bindist issues
Posted by Samisa Abeysinghe <sa...@gmail.com>.
make bindist
1. the resulting file is axis2c-bin-0.92-linux.tar.gz, but this is in
tar format, not zipped
2. docs are missing in the bin extract
3. .la files are present in lib folder of extract. Can we drop them?
4. xml_schema header files are missing in include
5. woden header files are missing in include
6. .a files and .la files are present in services sub folders. Can we
get rid of them?
7. current log files that are present at the time of running 'make
bindist' are packed into the log folder. We should not copy these old
log files in to dist
8. an FSF INSTALL file is copied into the samples INSTALL file. This is
*very* wrong.
9. can we link the README, ChangeLog, INSTALL, NEWS and COPYING files in
the samples folder to those in the root dist folder?
10. running ./configure in samples folder fails with the error:
"config.status: error: cannot find input file: client/Makefile.in"
Please help fix these.
Thanks,
Samisa...
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
Re: [Axis2] Double namespace validation mechanisms in sub build systems
Posted by Damitha Kumarage <da...@gmail.com>.
Samisa Abeysinghe wrote:
> Damitha Kumarage wrote:
>
>> Hi,
>> Samisa Abeysinghe wrote:
>>
>>> For woden and xml_schema, I see that the include folder has a sub
>>> folder with the respective name and then we have the include files
>>> in them with the prefix axis2_woden and axis2_xml_schema.
>>> This is validating namespaces twice.
>>>
>>> 1. We do not need the sub folder
>>
>>
>>
>> Actually I think what we should have followed is the folder base
>> namespace rather than prefix based one. I suggest
>> this at least for the new projects. Otherwise if we make a install to
>> default places in unix it would clutter standard
>> folders with axis2 prefixed files. It is very neat if they all go
>> inside a folder like /usr/local/inclue/woden
>>
>>> 2. we do not need the axis2_ part of the prefix (Yes I know we
>>> started with these as part of axis2, but not any more)
>>
>>
>>
>> we don't need any prefix if we put headers in a folder
>>
>> We separed those two projects from the main code base after they were
>> already started. That's why axis2 prefix.
>> Yes we need to remove axis2 prefix not only from xml_schema and woden
>> projects but also from other axis2 platform
>> emerging projects like security etc.
>
>
> Well, we initially came up with the idea of having a prefix for the
> header file name by looking at the APR project as our master guide.
> What they do is that, when they install, they install stuff to a
> folder in /usr/include/apr-[n], where n represents the versions.
> As an example, I have /usr/include/apr-0/, and inside that folder all
> the headers had either apr_ or apu_ prefix.
> What this basically means is that we can accommodate parallel versions
> to reside on the same machine.
>
> Hence why not we also adhere to the same standard. We install our
> header into axis2-0.92 in install location and all the headers are put
> there with axis2_, axiom_, woden_ and xml_schema_ prefixes. When
> including the header, the use does not have to use a folder prefix in
> #include. Also, no need to bother about putting multiple paths to -I,
> all that you need is -I/usr/include/axis2-0.92 (or whatever version of
> axis2 installed). Would that not be cleaner?
Ok this has been a historical debate with us(since Axis C++ time).
Unfortunately I have forgotten(or did not understand the first time)
about the plan you described here when I created the structure for
xml_schema and woden. Anyway I would like to make +1 for the above plan
and adhere to it. Also I'll remove axis2 prefix from
woden and xml_schema asap and prefix them with woden_ and xm_schema_
respectively.
thanks
Damitha
>
>>
>>>
>>> So I propose we remove those
>>>
>>> We also have axis2_om as our prefix for OM related stuff, shall we
>>> change that to axiom (yes this affects header name, struct name and
>>> method name prefixes as well as macro prefixes) But we better do it
>>> now, without waiting till 1.0 release.
>>
>>
>>
>> +1.
>>
>> It is better if we wait for these changes until atleast the initial
>> code base of xml_schema and woden is completed(In 3 or 4 days time).
>> Otherwise I would lost my concentration again(This first time I lost
>> is when having those env changes few days back).
>
>
> Well, I have lot my concentration already ;-) I have put my others
> tasks that I was working on to the *todo* waiting list as these are
> also *important* :)
> Anyway, yes, we can wait.
>
> Samisa...
>
>>
>> Thanks
>> Damitha
>>
>>>
>>> Thanks,
>>> Samisa...
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
Re: [Axis2] Double namespace validation mechanisms in sub build systems
Posted by Samisa Abeysinghe <sa...@gmail.com>.
Damitha Kumarage wrote:
> Hi,
> Samisa Abeysinghe wrote:
>
>> For woden and xml_schema, I see that the include folder has a sub
>> folder with the respective name and then we have the include files in
>> them with the prefix axis2_woden and axis2_xml_schema.
>> This is validating namespaces twice.
>>
>> 1. We do not need the sub folder
>
>
> Actually I think what we should have followed is the folder base
> namespace rather than prefix based one. I suggest
> this at least for the new projects. Otherwise if we make a install to
> default places in unix it would clutter standard
> folders with axis2 prefixed files. It is very neat if they all go
> inside a folder like /usr/local/inclue/woden
>
>> 2. we do not need the axis2_ part of the prefix (Yes I know we
>> started with these as part of axis2, but not any more)
>
>
> we don't need any prefix if we put headers in a folder
>
> We separed those two projects from the main code base after they were
> already started. That's why axis2 prefix.
> Yes we need to remove axis2 prefix not only from xml_schema and woden
> projects but also from other axis2 platform
> emerging projects like security etc.
Well, we initially came up with the idea of having a prefix for the
header file name by looking at the APR project as our master guide.
What they do is that, when they install, they install stuff to a folder
in /usr/include/apr-[n], where n represents the versions.
As an example, I have /usr/include/apr-0/, and inside that folder all
the headers had either apr_ or apu_ prefix.
What this basically means is that we can accommodate parallel versions
to reside on the same machine.
Hence why not we also adhere to the same standard. We install our header
into axis2-0.92 in install location and all the headers are put there
with axis2_, axiom_, woden_ and xml_schema_ prefixes. When including the
header, the use does not have to use a folder prefix in #include. Also,
no need to bother about putting multiple paths to -I, all that you need
is -I/usr/include/axis2-0.92 (or whatever version of axis2 installed).
Would that not be cleaner?
>
>>
>> So I propose we remove those
>>
>> We also have axis2_om as our prefix for OM related stuff, shall we
>> change that to axiom (yes this affects header name, struct name and
>> method name prefixes as well as macro prefixes) But we better do it
>> now, without waiting till 1.0 release.
>
>
> +1.
>
> It is better if we wait for these changes until atleast the initial
> code base of xml_schema and woden is completed(In 3 or 4 days time).
> Otherwise I would lost my concentration again(This first time I lost
> is when having those env changes few days back).
Well, I have lot my concentration already ;-) I have put my others tasks
that I was working on to the *todo* waiting list as these are also
*important* :)
Anyway, yes, we can wait.
Samisa...
>
> Thanks
> Damitha
>
>>
>> Thanks,
>> Samisa...
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
Re: [Axis2] Double namespace validation mechanisms in sub build systems
Posted by Damitha Kumarage <da...@gmail.com>.
Hi,
Samisa Abeysinghe wrote:
> For woden and xml_schema, I see that the include folder has a sub
> folder with the respective name and then we have the include files in
> them with the prefix axis2_woden and axis2_xml_schema.
> This is validating namespaces twice.
>
> 1. We do not need the sub folder
Actually I think what we should have followed is the folder base
namespace rather than prefix based one. I suggest
this at least for the new projects. Otherwise if we make a install to
default places in unix it would clutter standard
folders with axis2 prefixed files. It is very neat if they all go inside
a folder like /usr/local/inclue/woden
> 2. we do not need the axis2_ part of the prefix (Yes I know we started
> with these as part of axis2, but not any more)
we don't need any prefix if we put headers in a folder
We separed those two projects from the main code base after they were
already started. That's why axis2 prefix.
Yes we need to remove axis2 prefix not only from xml_schema and woden
projects but also from other axis2 platform
emerging projects like security etc.
>
> So I propose we remove those
>
> We also have axis2_om as our prefix for OM related stuff, shall we
> change that to axiom (yes this affects header name, struct name and
> method name prefixes as well as macro prefixes) But we better do it
> now, without waiting till 1.0 release.
+1.
It is better if we wait for these changes until atleast the initial code
base of xml_schema and woden is completed(In 3 or 4 days time).
Otherwise I would lost my concentration again(This first time I lost is
when having those env changes few days back).
Thanks
Damitha
>
> Thanks,
> Samisa...
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
[Axis2] Double namespace validation mechanisms in sub build systems
Posted by Samisa Abeysinghe <sa...@gmail.com>.
For woden and xml_schema, I see that the include folder has a sub folder
with the respective name and then we have the include files in them with
the prefix axis2_woden and axis2_xml_schema.
This is validating namespaces twice.
1. We do not need the sub folder
2. we do not need the axis2_ part of the prefix (Yes I know we started
with these as part of axis2, but not any more)
So I propose we remove those
We also have axis2_om as our prefix for OM related stuff, shall we
change that to axiom (yes this affects header name, struct name and
method name prefixes as well as macro prefixes) But we better do it now,
without waiting till 1.0 release.
Thanks,
Samisa...
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
Re: [Axis2] PHP XML IN-OUT Message Receiver
Posted by Nabeel Yoosuf <na...@gmail.com>.
On 6/5/06, Samisa Abeysinghe <sa...@gmail.com> wrote:
>
> Nabeel wrote:
>
> > It's an independent piece of code which I'd like to license under ASF.
>
> My only concern is holding non-core stuff in Axis2/C trunk. How many
> users would want it and who would maintain it are key issues.
> BTW, you can always give it away with Apache License, and that does not
> mean that we have to have the code in Axis2/c trunk.
Yes. I understand your concerns. May be we'll have to keep such code in
an independent repo.
-Nabeel
Samisa...
>
> > -Nabeel
> > Samisa Abeysinghe wrote:
> >
> >> Nabeel Yoosuf wrote:
> >>
> >>> IMHO, Ideally this should be kept in a location independent of both
> >>> PHP and Axis2/C repos. If a user wants to have PHP web services in
> >>> C, (s)he needs to first download PHP and Axis2/C. Then download and
> >>> compile the receiver using the downloaded PHP and Axis2/C libraries.
> >>> Since, neither PHP nor Axis2/C is dependent on this receiver; it
> >>> just uses what is provided by them.
> >>
> >>
> >>
> >> Well, PHP server side is dependent on this isnt it. If I understand
> >> correct, without this receiver, PHP server side cannot work.
> >>
> >>>
> >>> We can find reason for and againts keeping custom receivers in Axis2
> >>> repo. I wonder how Axis2 java guys keep custom receivers? What if I
> >>> write a C++ message receiver?
> >>
> >>
> >>
> >> If it is based on pure Axis2/C API, then it could be in Axis2/C code
> >> base. If it is dependent on external APIs and if those APIs are not
> >> required by the Axis2/C core, I am not sure if it should be placed in
> >> the Axis2/C code base. For the C++ case, I do not think it is the job
> >> of the main Axis2/C code base to support it - it is an extension, a
> >> wrapper. But it is different from the PHP case, where it does not use
> >> a specific external API.
> >>
> >> Samisa...
> >>
> >>>
> >>> -Nabeel
> >>>
> >>> On 6/4/06, *Samisa Abeysinghe* <samisa.abeysinghe@gmail.com
> >>> <ma...@gmail.com>> wrote:
> >>>
> >>> I think it is better if we keep it in a PHP related repo.
> >>> It is the PHP code that is based on Axis2/C, not that Axis2/C
> >>> depends on
> >>> PHP. Hence it is the responsibility of the PHP module to hold this
> >>> code
> >>> IMHO.
> >>>
> >>> Thanks,
> >>> Samisa...
> >>>
> >>> Nabeel Yoosuf wrote:
> >>>
> >>> > PHP XML IN-OUT Message Receiver
> >>> > -------------------------------------------------------
> >>> >
> >>> > This message receiver allows you to write your web services
> >>> > implementation in PHP and expose it through Axis2/C engine.
> >>> >
> >>> > It uses PHP embed SAPI to call PHP code from C.
> >>> >
> >>> > The README file gives some details about the receiver and how to
> >>> > install it.
> >>> >
> >>> > There are two examples shipped with this. echo and math
> >>> services. Drop
> >>> > them into services folder and you can call it from any client!
> >>> >
> >>> > I think this should go to a folder called "contributions" inside
> >>> > Axis2/C SVN. (c/contributions/php_xml_msg_recv/)
> >>> >
> >>> > -Nabeel
> >>> >
> >>>
> >>>
> >------------------------------------------------------------------------
> >>>
> >>> >
> >>>
> >>> >---------------------------------------------------------------------
> >>>
> >>> >To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
> >>> <ma...@ws.apache.org>
> >>> >For additional commands, e-mail: axis-c-dev-help@ws.apache.org
> >>> <ma...@ws.apache.org>
> >>> >
> >>>
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
> >>> <ma...@ws.apache.org>
> >>> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
> >>> <ma...@ws.apache.org>
> >>>
> >>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
> >>
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-c-dev-help@ws.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>
>
Re: [Axis2] PHP XML IN-OUT Message Receiver
Posted by Samisa Abeysinghe <sa...@gmail.com>.
Nabeel wrote:
> It's an independent piece of code which I'd like to license under ASF.
My only concern is holding non-core stuff in Axis2/C trunk. How many
users would want it and who would maintain it are key issues.
BTW, you can always give it away with Apache License, and that does not
mean that we have to have the code in Axis2/c trunk.
Samisa...
> -Nabeel
> Samisa Abeysinghe wrote:
>
>> Nabeel Yoosuf wrote:
>>
>>> IMHO, Ideally this should be kept in a location independent of both
>>> PHP and Axis2/C repos. If a user wants to have PHP web services in
>>> C, (s)he needs to first download PHP and Axis2/C. Then download and
>>> compile the receiver using the downloaded PHP and Axis2/C libraries.
>>> Since, neither PHP nor Axis2/C is dependent on this receiver; it
>>> just uses what is provided by them.
>>
>>
>>
>> Well, PHP server side is dependent on this isnt it. If I understand
>> correct, without this receiver, PHP server side cannot work.
>>
>>>
>>> We can find reason for and againts keeping custom receivers in Axis2
>>> repo. I wonder how Axis2 java guys keep custom receivers? What if I
>>> write a C++ message receiver?
>>
>>
>>
>> If it is based on pure Axis2/C API, then it could be in Axis2/C code
>> base. If it is dependent on external APIs and if those APIs are not
>> required by the Axis2/C core, I am not sure if it should be placed in
>> the Axis2/C code base. For the C++ case, I do not think it is the job
>> of the main Axis2/C code base to support it - it is an extension, a
>> wrapper. But it is different from the PHP case, where it does not use
>> a specific external API.
>>
>> Samisa...
>>
>>>
>>> -Nabeel
>>>
>>> On 6/4/06, *Samisa Abeysinghe* <samisa.abeysinghe@gmail.com
>>> <ma...@gmail.com>> wrote:
>>>
>>> I think it is better if we keep it in a PHP related repo.
>>> It is the PHP code that is based on Axis2/C, not that Axis2/C
>>> depends on
>>> PHP. Hence it is the responsibility of the PHP module to hold this
>>> code
>>> IMHO.
>>>
>>> Thanks,
>>> Samisa...
>>>
>>> Nabeel Yoosuf wrote:
>>>
>>> > PHP XML IN-OUT Message Receiver
>>> > -------------------------------------------------------
>>> >
>>> > This message receiver allows you to write your web services
>>> > implementation in PHP and expose it through Axis2/C engine.
>>> >
>>> > It uses PHP embed SAPI to call PHP code from C.
>>> >
>>> > The README file gives some details about the receiver and how to
>>> > install it.
>>> >
>>> > There are two examples shipped with this. echo and math
>>> services. Drop
>>> > them into services folder and you can call it from any client!
>>> >
>>> > I think this should go to a folder called "contributions" inside
>>> > Axis2/C SVN. (c/contributions/php_xml_msg_recv/)
>>> >
>>> > -Nabeel
>>> >
>>>
>>> >------------------------------------------------------------------------
>>>
>>> >
>>>
>>> >---------------------------------------------------------------------
>>>
>>> >To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
>>> <ma...@ws.apache.org>
>>> >For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>>> <ma...@ws.apache.org>
>>> >
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
>>> <ma...@ws.apache.org>
>>> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>>> <ma...@ws.apache.org>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
Re: [Axis2] PHP XML IN-OUT Message Receiver
Posted by Nabeel <na...@wso2.com>.
It's an independent piece of code which I'd like to license under ASF.
-Nabeel
Samisa Abeysinghe wrote:
> Nabeel Yoosuf wrote:
>
>> IMHO, Ideally this should be kept in a location independent of both
>> PHP and Axis2/C repos. If a user wants to have PHP web services in C,
>> (s)he needs to first download PHP and Axis2/C. Then download and
>> compile the receiver using the downloaded PHP and Axis2/C libraries.
>> Since, neither PHP nor Axis2/C is dependent on this receiver; it
>> just uses what is provided by them.
>
>
> Well, PHP server side is dependent on this isnt it. If I understand
> correct, without this receiver, PHP server side cannot work.
>
>>
>> We can find reason for and againts keeping custom receivers in Axis2
>> repo. I wonder how Axis2 java guys keep custom receivers? What if I
>> write a C++ message receiver?
>
>
> If it is based on pure Axis2/C API, then it could be in Axis2/C code
> base. If it is dependent on external APIs and if those APIs are not
> required by the Axis2/C core, I am not sure if it should be placed in
> the Axis2/C code base. For the C++ case, I do not think it is the job
> of the main Axis2/C code base to support it - it is an extension, a
> wrapper. But it is different from the PHP case, where it does not use
> a specific external API.
>
> Samisa...
>
>>
>> -Nabeel
>>
>> On 6/4/06, *Samisa Abeysinghe* <samisa.abeysinghe@gmail.com
>> <ma...@gmail.com>> wrote:
>>
>> I think it is better if we keep it in a PHP related repo.
>> It is the PHP code that is based on Axis2/C, not that Axis2/C
>> depends on
>> PHP. Hence it is the responsibility of the PHP module to hold this
>> code
>> IMHO.
>>
>> Thanks,
>> Samisa...
>>
>> Nabeel Yoosuf wrote:
>>
>> > PHP XML IN-OUT Message Receiver
>> > -------------------------------------------------------
>> >
>> > This message receiver allows you to write your web services
>> > implementation in PHP and expose it through Axis2/C engine.
>> >
>> > It uses PHP embed SAPI to call PHP code from C.
>> >
>> > The README file gives some details about the receiver and how to
>> > install it.
>> >
>> > There are two examples shipped with this. echo and math
>> services. Drop
>> > them into services folder and you can call it from any client!
>> >
>> > I think this should go to a folder called "contributions" inside
>> > Axis2/C SVN. (c/contributions/php_xml_msg_recv/)
>> >
>> > -Nabeel
>> >
>>
>> >------------------------------------------------------------------------
>>
>> >
>>
>> >---------------------------------------------------------------------
>>
>> >To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
>> <ma...@ws.apache.org>
>> >For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>> <ma...@ws.apache.org>
>> >
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
>> <ma...@ws.apache.org>
>> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>> <ma...@ws.apache.org>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
Re: [Axis2] PHP XML IN-OUT Message Receiver
Posted by Samisa Abeysinghe <sa...@gmail.com>.
Nabeel Yoosuf wrote:
> IMHO, Ideally this should be kept in a location independent of both
> PHP and Axis2/C repos. If a user wants to have PHP web services in C,
> (s)he needs to first download PHP and Axis2/C. Then download and
> compile the receiver using the downloaded PHP and Axis2/C libraries.
> Since, neither PHP nor Axis2/C is dependent on this receiver; it just
> uses what is provided by them.
Well, PHP server side is dependent on this isnt it. If I understand
correct, without this receiver, PHP server side cannot work.
>
> We can find reason for and againts keeping custom receivers in Axis2
> repo. I wonder how Axis2 java guys keep custom receivers? What if I
> write a C++ message receiver?
If it is based on pure Axis2/C API, then it could be in Axis2/C code
base. If it is dependent on external APIs and if those APIs are not
required by the Axis2/C core, I am not sure if it should be placed in
the Axis2/C code base. For the C++ case, I do not think it is the job of
the main Axis2/C code base to support it - it is an extension, a
wrapper. But it is different from the PHP case, where it does not use a
specific external API.
Samisa...
>
> -Nabeel
>
> On 6/4/06, *Samisa Abeysinghe* <samisa.abeysinghe@gmail.com
> <ma...@gmail.com>> wrote:
>
> I think it is better if we keep it in a PHP related repo.
> It is the PHP code that is based on Axis2/C, not that Axis2/C
> depends on
> PHP. Hence it is the responsibility of the PHP module to hold this
> code
> IMHO.
>
> Thanks,
> Samisa...
>
> Nabeel Yoosuf wrote:
>
> > PHP XML IN-OUT Message Receiver
> > -------------------------------------------------------
> >
> > This message receiver allows you to write your web services
> > implementation in PHP and expose it through Axis2/C engine.
> >
> > It uses PHP embed SAPI to call PHP code from C.
> >
> > The README file gives some details about the receiver and how to
> > install it.
> >
> > There are two examples shipped with this. echo and math
> services. Drop
> > them into services folder and you can call it from any client!
> >
> > I think this should go to a folder called "contributions" inside
> > Axis2/C SVN. (c/contributions/php_xml_msg_recv/)
> >
> > -Nabeel
> >
> >------------------------------------------------------------------------
> >
> >---------------------------------------------------------------------
>
> >To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
> <ma...@ws.apache.org>
> >For additional commands, e-mail: axis-c-dev-help@ws.apache.org
> <ma...@ws.apache.org>
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
> <ma...@ws.apache.org>
> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
> <ma...@ws.apache.org>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
Re: [Axis2] PHP XML IN-OUT Message Receiver
Posted by Nabeel Yoosuf <na...@gmail.com>.
IMHO, Ideally this should be kept in a location independent of both PHP and
Axis2/C repos. If a user wants to have PHP web services in C, (s)he needs to
first download PHP and Axis2/C. Then download and compile the receiver
using the downloaded PHP and Axis2/C libraries. Since, neither PHP nor
Axis2/C is dependent on this receiver; it just uses what is provided by
them.
We can find reason for and againts keeping custom receivers in Axis2 repo. I
wonder how Axis2 java guys keep custom receivers? What if I write a C++
message receiver?
-Nabeel
On 6/4/06, Samisa Abeysinghe <sa...@gmail.com> wrote:
>
> I think it is better if we keep it in a PHP related repo.
> It is the PHP code that is based on Axis2/C, not that Axis2/C depends on
> PHP. Hence it is the responsibility of the PHP module to hold this code
> IMHO.
>
> Thanks,
> Samisa...
>
> Nabeel Yoosuf wrote:
>
> > PHP XML IN-OUT Message Receiver
> > -------------------------------------------------------
> >
> > This message receiver allows you to write your web services
> > implementation in PHP and expose it through Axis2/C engine.
> >
> > It uses PHP embed SAPI to call PHP code from C.
> >
> > The README file gives some details about the receiver and how to
> > install it.
> >
> > There are two examples shipped with this. echo and math services. Drop
> > them into services folder and you can call it from any client!
> >
> > I think this should go to a folder called "contributions" inside
> > Axis2/C SVN. (c/contributions/php_xml_msg_recv/)
> >
> > -Nabeel
> >
> >------------------------------------------------------------------------
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
> >For additional commands, e-mail: axis-c-dev-help@ws.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>
>
Re: [Axis2] PHP XML IN-OUT Message Receiver
Posted by Samisa Abeysinghe <sa...@gmail.com>.
I think it is better if we keep it in a PHP related repo.
It is the PHP code that is based on Axis2/C, not that Axis2/C depends on
PHP. Hence it is the responsibility of the PHP module to hold this code
IMHO.
Thanks,
Samisa...
Nabeel Yoosuf wrote:
> PHP XML IN-OUT Message Receiver
> -------------------------------------------------------
>
> This message receiver allows you to write your web services
> implementation in PHP and expose it through Axis2/C engine.
>
> It uses PHP embed SAPI to call PHP code from C.
>
> The README file gives some details about the receiver and how to
> install it.
>
> There are two examples shipped with this. echo and math services. Drop
> them into services folder and you can call it from any client!
>
> I think this should go to a folder called "contributions" inside
> Axis2/C SVN. (c/contributions/php_xml_msg_recv/)
>
> -Nabeel
>
>------------------------------------------------------------------------
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
>For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org