You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Jean-Sebastien Delfino <js...@apache.org> on 2012/11/22 20:31:56 UTC
Porting Tuscany C++ to C++11 and some code cleanup
Hi all,
Happy Thanksgiving :). I'm going to have a little bit of spare time on the
long weekend to do some cleanup of Tuscany C++.
I'm planning to do some code refactoring to start leveraging some of the
new C++11 standard constructs (replace the current functors with C++11
lambda expressions for example). I'll also try to do some more general
cleanup of the code base and improvements to a few areas like the JSON
support (which currently requires SpiderMonkey, that's overkill) and the
server hosting module.
These changes should simplify the code base a bit and bring significant
performance improvements as well. It'd be nice to have another release at
some point... perhaps on one of the next holiday breaks if I get enough
spare time again, or if others would like to help...
HTH
- Jean-Sebastien
Re: Porting Tuscany C++ to C++11 and some code cleanup
Posted by Jean-Sebastien Delfino <js...@apache.org>.
On Mon, Jan 14, 2013 at 1:03 PM, Thomas Gentsch <tg...@e-tge.de> wrote:
> On Sun, 2013-01-13 at 23:35 -0800, Jean-Sebastien Delfino wrote:
> > On Mon, Jan 7, 2013 at 1:28 PM, Thomas Gentsch <tg...@e-tge.de> wrote:
>
...
> >
> > Q: Is there some kind of request routing?
> > A: Local calls are resolved during OS-loader-time. One
> > component calling
> > another is written as regular C++ code which results in
> > compiled code as
> > unresolved reference that must be satisfied during runtime by
> > the target
> > component which in turn must be loaded as shared library
> >
> >
> >
> > No, if I remember correctly (as M3 was a long time ago,)
>
> :-)
>
> > wires were resolved by Composite::resolveWires, then invocation of a
> > component involved CPPServiceWrapper::getServiceWrapper to load the
> > component library, lookup a factory function named after the service
> > name, create an instance of CPPServiceWrapper, and eventually
> > executing generated code in CPPServiceWrapper::invokeService to
> > dispatch the call to the target C++ component method.
>
> But then the wrapper and proxy must exist - either hand-written or
> WSDL-generated.
Yes
> The CppCalculator example though has neither. I did not
> verify all the others, most have WSDL as it seems.
> Maybe as long everything happens within *one* lib ... ?
>
>
Proxies and wrappers are generated at build time. That's why you can't find
them in the source tree, as we usually don't commit generated build outputs
to the Apache source repository.
> Actually I was thinking that its even not a bad idea to let the OS
> loader (or even the linker) resolve the calls as it is probably the
> fastest way possible.
>
>
That could be challenging in the following configurations:
a) several components, say C1 and C2, implementing the same service WSDL
interface 'I' + operation 'o' (as the linker wouldn't know which one to
pick);
b) dynamic wiring decided by a component's implementation logic (as the
linking would happen too early);
c) a composition of components written in different languages, in
particular scripting languages (as linking would only apply to C and C++
components).
... but that's still an interesting idea to explore. I've not thought too
much about it, but you may be able to come up with a generation scheme
addressing some of these challenges.
...
>
> > I've worked on C++ M3, trunk and even the Java project so I can
> > imagine why someone would prefer one or the other. The good thing is
> > that they're here in the open and you can do what you want with the
> > code, use the bits you prefer, mix them, or even contribute to
> > maintain or change them to something you like, if you're interested.
>
> True, but the real power of open-source is if the "community" jointly
> works on the same thing. Of course I cannot force anybody :-)
> Also, I quite like the idea of following a standard (if it is any good,
> which I cannot really tell yet).
>
>
+1
> So, in theory, I could start a project, let's say "sca-oasis", based on
> M3 ... originally I'd be the only one working on it, maybe others join,
> maybe not. Would that then still be "Apache Tuscany"?
>
>
For it to be 'Apache Tuscany' you'd have to discuss and contribute your
ideas to the Apache Tuscany community here in the open -- which you are
doing right now :) -- and contribute code changes or additions to the
Apache Tuscany project repository. If you're interested, you can start with
patches in JIRA issues (which allow you to grant license to Apache for your
contributions) and at some point the community can even give you
committership.
We should discuss what you have in mind on this list (I'd suggest a
different thread as this one is getting long) but for example 'adding
support for the OASIS SCA assembly spec to the M3 code', 'integrating some
of the M3 code and trunk', 'adding a code generator to trunk (the one from
M3 or another)' or any other ideas you have, would all be valid ideas to
discuss and evolve the project IMO.
...
>
> > I'm not sure if you're talking about validating the data exchanged
> > with SCA components (which could be done with a validating proxy) or
> > about generating static code from schema type definitions, but both
> > approaches should work nicely along M3 or trunk (for the latter you'd
> > need a generator like scagen on top of the runtime invocation
> > mechanism.)
>
> Maybe here I'm in the SDO world again ... :-) All the schema/type stuff
> is nicely integrated and I don't need to directly deal with libxml2 or
> so ...
>
>
If you like SDO, that could be an area where you could contribute too. For
example (just thinking out loud) you could try to get SDO to work with
JSON, as JSON is getting so much traction these days, or (going back to
your code generation idea), first make sure that SDO still works with
modern C++ compilers and the latest Libxml2 parser, re-activate its build
etc, then generate C++ SCA component skeletons that use SDOs.
- Jean-Sebastien
Re: Porting Tuscany C++ to C++11 and some code cleanup
Posted by Thomas Gentsch <tg...@e-tge.de>.
On Sun, 2013-01-13 at 23:35 -0800, Jean-Sebastien Delfino wrote:
> On Mon, Jan 7, 2013 at 1:28 PM, Thomas Gentsch <tg...@e-tge.de> wrote:
>
> Hello JS,
>
>
>
> Hi Thomas, Happy New Year!
Many thx! Same back!!
> now, I did some more reading etc and believe now that I mostly
> understand what's going on :-)
>
> The main missing pieces were these (correct? Possibly my
> terminology is
> a bit fuzzy :-):
> Q: When are SDOs used (in SCA M3) and when not?
> A: If an interface of a service uses complex types as in/out
> params or
> return value, otherwise simple types (like int, bool, string)
> are used.
> Complex types (i.e. class instances) an XSD are passed in/out
> as SDO
>
>
>
> Yes
>
> Q: Is there some kind of request routing?
> A: Local calls are resolved during OS-loader-time. One
> component calling
> another is written as regular C++ code which results in
> compiled code as
> unresolved reference that must be satisfied during runtime by
> the target
> component which in turn must be loaded as shared library
>
>
>
> No, if I remember correctly (as M3 was a long time ago,)
:-)
> wires were resolved by Composite::resolveWires, then invocation of a
> component involved CPPServiceWrapper::getServiceWrapper to load the
> component library, lookup a factory function named after the service
> name, create an instance of CPPServiceWrapper, and eventually
> executing generated code in CPPServiceWrapper::invokeService to
> dispatch the call to the target C++ component method.
But then the wrapper and proxy must exist - either hand-written or
WSDL-generated. The CppCalculator example though has neither. I did not
verify all the others, most have WSDL as it seems.
Maybe as long everything happens within *one* lib ... ?
Actually I was thinking that its even not a bad idea to let the OS
loader (or even the linker) resolve the calls as it is probably the
fastest way possible.
But, OK, will look again :-)
> In trunk, the equivalent of invokeService is the apply function, and
> currently needs to be written by hand as scagen has not been
> maintained (but could be brought back if somebody was interested in
> maintaining it).
>
> Q: What is the purpose of composite files with pure C++
> modules?
> A: If a composite consists only of local components all calls
> are
> resolved by the OS loader. In that case basically the
> composite
> definition file mainly states which interfaces are in which
> shared lib
> and in which order are the libs to be loaded.
>
>
>
> See above, both M3 and trunk resolve wiring dynamically.
>
> Q: How are remote request handled?
> A: Remote interfaces are described using WSDL, which must be
> processed
> using the tool scagen to generate a "ServiceWrapper" and a
> "ServiceProxy" that act as client (proxy) and server (wrapper)
> stubs.
>
>
> In M3 ServiceWrapper and ServiceProxy were generated from WSDL by
> scagen and were used for both local and remote invocations.
>
>
> However, some things are still unclear:
> Q: If there is nothing like request routing, how does the
> "wiring" work
> if the calls are actually hardcoded?
>
>
>
> See above.
>
> Besides of these questions a few non-technical ones:
> Q: The trunk code stream looks to me like a complete re-write.
> With even
> the component interfaces changing and nobody complaining I
> guess that
> there is nobody actually really using Tuscany SCA C++?
>
>
> I just checked M3 again and it looks that way now when we compare
> trunk in 2013 and M3 from 2006/2007. The code has evolved slowly but
> after 6 years I'm not really surprised.
>
> Q: Besides of people using it, is there anybody besides you
> working on
> it?
>
>
> I'm not really sure. I've been the only one pushing changes to trunk
> recently. I noticed a new lightweight-sca clone branch recently but
> can't remember who created it. When I get tech questions here, in
> email or IRC, and find time, I try to answer without bothering people
> asking what they're doing with the code, so there may be more clone
> branches here or on github for example, as the code is open to anyone
> who wants to hack on it.
> Q: To which extent are both the M3 and trunk versions
> "stable"? M3
> probably in the sense that nobody works on it anymore but is
> it mostly
> complete/usable?
>
>
> M3 has not changed since 2007. Trunk is moving slowly as I only spend
> a little spare time on it on some weekends or holidays. Complete and
> usable are subjective notions, as IMO an open-source project is not
> 'complete' as long as people are still interested in evolving it, and
> 'usable' depends on the use case.
>
> Q: What about interoperability with Tuscany Java? I suppose
> both M3 and
> trunk are OK as long as the binding is the same (and on the
> wire it is
> XML or whatever anyway). Which common binding types exist?
>
>
> With M3, REST. With trunk, REST and SOAP.
>
>
> Generally I have to admit that I liked the old implementation
> more,
> though this maybe caused by the new language features in trunk
> I'm not
> familiar with yet.
>
>
> I've worked on C++ M3, trunk and even the Java project so I can
> imagine why someone would prefer one or the other. The good thing is
> that they're here in the open and you can do what you want with the
> code, use the bits you prefer, mix them, or even contribute to
> maintain or change them to something you like, if you're interested.
True, but the real power of open-source is if the "community" jointly
works on the same thing. Of course I cannot force anybody :-)
Also, I quite like the idea of following a standard (if it is any good,
which I cannot really tell yet).
So, in theory, I could start a project, let's say "sca-oasis", based on
M3 ... originally I'd be the only one working on it, maybe others join,
maybe not. Would that then still be "Apache Tuscany"?
Maybe I'll post something in tuscany-users like "anybody using it?" ...
>
> Q: With the new value/list types, if there is no relation with
> XSD
> anymore, can you also query information about object types,
> e.g. which
> properties a class shall have? This is probably not needed in
> the SCA
> code, but maybe in custom extensions ...
>
>
> There isn't anything in the runtime to allow you to query the types,
> but if you have an XML (or JSON) schema, and a schema library that
> you'd like to use with your types, there's no reason why you couldn't
> use that library along with SCA.
>
> Also, type enforcement is not necessarily a disadvantage
> (admittedly
> slower though)
>
>
> I'm not sure if you're talking about validating the data exchanged
> with SCA components (which could be done with a validating proxy) or
> about generating static code from schema type definitions, but both
> approaches should work nicely along M3 or trunk (for the latter you'd
> need a generator like scagen on top of the runtime invocation
> mechanism.)
Maybe here I'm in the SDO world again ... :-) All the schema/type stuff
is nicely integrated and I don't need to directly deal with libxml2 or
so ...
Many thx again!!!
tge
>
> Many thx again + regards,
> the
>
> On Wed, 2013-01-02 at 23:49 -0800, Jean-Sebastien Delfino
> wrote:
> > On Sat, Dec 29, 2012 at 6:20 PM, Jean-Sebastien Delfino
> > <js...@apache.org> wrote:
> > Hi all,
> >
> >
> > I had a few more offline Q&A exchanges with Thomas,
> and
> > thought it'd be useful to share a summary here:
> >
> >
> > Q: In the C++ trunk, is DataObject now replaced by
> > tuscany::value and tuscany::list?
> >
> >
> > A: Yes
> >
> >
> >
> >
> > BTW I just committed a number of changes I made over the
> holidays,
> > including some improvements to tuscany::value and
> tuscany::list, in
> > particular to work with lists, nested lists and trees of
> key/value
> > pairs (aka associations) as well as some minor improvements
> to handle
> > comparisons of floating point number values.
> >
> >
> > - Jean-Sebastien
>
>
>
>
>
--
........................................................
Thomas Gentsch
Römerstr. 76
70180 Stuttgart
Tel : (+49) 0711 - 46915652
mobil : (+49) 0173 - 6620507
e-mail: tg@e-tge.de
........................................................
Re: Porting Tuscany C++ to C++11 and some code cleanup
Posted by Jean-Sebastien Delfino <js...@apache.org>.
On Mon, Jan 7, 2013 at 1:28 PM, Thomas Gentsch <tg...@e-tge.de> wrote:
>
> Hello JS,
>
>
Hi Thomas, Happy New Year!
> now, I did some more reading etc and believe now that I mostly
> understand what's going on :-)
>
> The main missing pieces were these (correct? Possibly my terminology is
> a bit fuzzy :-):
> Q: When are SDOs used (in SCA M3) and when not?
> A: If an interface of a service uses complex types as in/out params or
> return value, otherwise simple types (like int, bool, string) are used.
> Complex types (i.e. class instances) an XSD are passed in/out as SDO
>
>
Yes
> Q: Is there some kind of request routing?
> A: Local calls are resolved during OS-loader-time. One component calling
> another is written as regular C++ code which results in compiled code as
> unresolved reference that must be satisfied during runtime by the target
> component which in turn must be loaded as shared library
>
>
No, if I remember correctly (as M3 was a long time ago,) wires were
resolved by Composite::resolveWires, then invocation of a component
involved CPPServiceWrapper::getServiceWrapper to load the component
library, lookup a factory function named after the service name, create an
instance of CPPServiceWrapper, and eventually executing generated code
in CPPServiceWrapper::invokeService to dispatch the call to the target C++
component method.
In trunk, the equivalent of invokeService is the apply function, and
currently needs to be written by hand as scagen has not been maintained
(but could be brought back if somebody was interested in maintaining it).
> Q: What is the purpose of composite files with pure C++ modules?
> A: If a composite consists only of local components all calls are
> resolved by the OS loader. In that case basically the composite
> definition file mainly states which interfaces are in which shared lib
> and in which order are the libs to be loaded.
>
>
See above, both M3 and trunk resolve wiring dynamically.
> Q: How are remote request handled?
> A: Remote interfaces are described using WSDL, which must be processed
> using the tool scagen to generate a "ServiceWrapper" and a
> "ServiceProxy" that act as client (proxy) and server (wrapper) stubs.
>
In M3 ServiceWrapper and ServiceProxy were generated from WSDL by scagen
and were used for both local and remote invocations.
>
> However, some things are still unclear:
> Q: If there is nothing like request routing, how does the "wiring" work
> if the calls are actually hardcoded?
>
>
See above.
> Besides of these questions a few non-technical ones:
> Q: The trunk code stream looks to me like a complete re-write. With even
> the component interfaces changing and nobody complaining I guess that
> there is nobody actually really using Tuscany SCA C++?
>
I just checked M3 again and it looks that way now when we compare trunk in
2013 and M3 from 2006/2007. The code has evolved slowly but after 6 years
I'm not really surprised.
> Q: Besides of people using it, is there anybody besides you working on
> it?
>
I'm not really sure. I've been the only one pushing changes to trunk
recently. I noticed a new lightweight-sca clone branch recently but can't
remember who created it. When I get tech questions here, in email or IRC,
and find time, I try to answer without bothering people asking what they're
doing with the code, so there may be more clone branches here or on github
for example, as the code is open to anyone who wants to hack on it.
> Q: To which extent are both the M3 and trunk versions "stable"? M3
> probably in the sense that nobody works on it anymore but is it mostly
> complete/usable?
>
M3 has not changed since 2007. Trunk is moving slowly as I only spend a
little spare time on it on some weekends or holidays. Complete and usable
are subjective notions, as IMO an open-source project is not 'complete' as
long as people are still interested in evolving it, and 'usable' depends on
the use case.
> Q: What about interoperability with Tuscany Java? I suppose both M3 and
> trunk are OK as long as the binding is the same (and on the wire it is
> XML or whatever anyway). Which common binding types exist?
>
With M3, REST. With trunk, REST and SOAP.
>
> Generally I have to admit that I liked the old implementation more,
> though this maybe caused by the new language features in trunk I'm not
> familiar with yet.
>
I've worked on C++ M3, trunk and even the Java project so I can imagine why
someone would prefer one or the other. The good thing is that they're here
in the open and you can do what you want with the code, use the bits you
prefer, mix them, or even contribute to maintain or change them to
something you like, if you're interested.
>
> Q: With the new value/list types, if there is no relation with XSD
> anymore, can you also query information about object types, e.g. which
> properties a class shall have? This is probably not needed in the SCA
> code, but maybe in custom extensions ...
>
There isn't anything in the runtime to allow you to query the types, but if
you have an XML (or JSON) schema, and a schema library that you'd like to
use with your types, there's no reason why you couldn't use that library
along with SCA.
> Also, type enforcement is not necessarily a disadvantage (admittedly
> slower though)
>
I'm not sure if you're talking about validating the data exchanged with SCA
components (which could be done with a validating proxy) or about
generating static code from schema type definitions, but both approaches
should work nicely along M3 or trunk (for the latter you'd need a generator
like scagen on top of the runtime invocation mechanism.)
>
> Many thx again + regards,
> the
>
> On Wed, 2013-01-02 at 23:49 -0800, Jean-Sebastien Delfino wrote:
> > On Sat, Dec 29, 2012 at 6:20 PM, Jean-Sebastien Delfino
> > <js...@apache.org> wrote:
> > Hi all,
> >
> >
> > I had a few more offline Q&A exchanges with Thomas, and
> > thought it'd be useful to share a summary here:
> >
> >
> > Q: In the C++ trunk, is DataObject now replaced by
> > tuscany::value and tuscany::list?
> >
> >
> > A: Yes
> >
> >
> >
> >
> > BTW I just committed a number of changes I made over the holidays,
> > including some improvements to tuscany::value and tuscany::list, in
> > particular to work with lists, nested lists and trees of key/value
> > pairs (aka associations) as well as some minor improvements to handle
> > comparisons of floating point number values.
> >
> >
> > - Jean-Sebastien
>
>
>
>
Re: Porting Tuscany C++ to C++11 and some code cleanup
Posted by Thomas Gentsch <tg...@e-tge.de>.
Hello JS,
now, I did some more reading etc and believe now that I mostly
understand what's going on :-)
The main missing pieces were these (correct? Possibly my terminology is
a bit fuzzy :-):
Q: When are SDOs used (in SCA M3) and when not?
A: If an interface of a service uses complex types as in/out params or
return value, otherwise simple types (like int, bool, string) are used.
Complex types (i.e. class instances) an XSD are passed in/out as SDO
Q: Is there some kind of request routing?
A: Local calls are resolved during OS-loader-time. One component calling
another is written as regular C++ code which results in compiled code as
unresolved reference that must be satisfied during runtime by the target
component which in turn must be loaded as shared library
Q: What is the purpose of composite files with pure C++ modules?
A: If a composite consists only of local components all calls are
resolved by the OS loader. In that case basically the composite
definition file mainly states which interfaces are in which shared lib
and in which order are the libs to be loaded.
Q: How are remote request handled?
A: Remote interfaces are described using WSDL, which must be processed
using the tool scagen to generate a "ServiceWrapper" and a
"ServiceProxy" that act as client (proxy) and server (wrapper) stubs.
However, some things are still unclear:
Q: If there is nothing like request routing, how does the "wiring" work
if the calls are actually hardcoded?
Besides of these questions a few non-technical ones:
Q: The trunk code stream looks to me like a complete re-write. With even
the component interfaces changing and nobody complaining I guess that
there is nobody actually really using Tuscany SCA C++?
Q: Besides of people using it, is there anybody besides you working on
it?
Q: To which extent are both the M3 and trunk versions "stable"? M3
probably in the sense that nobody works on it anymore but is it mostly
complete/usable?
Q: What about interoperability with Tuscany Java? I suppose both M3 and
trunk are OK as long as the binding is the same (and on the wire it is
XML or whatever anyway). Which common binding types exist?
Generally I have to admit that I liked the old implementation more,
though this maybe caused by the new language features in trunk I'm not
familiar with yet.
Q: With the new value/list types, if there is no relation with XSD
anymore, can you also query information about object types, e.g. which
properties a class shall have? This is probably not needed in the SCA
code, but maybe in custom extensions ...
Also, type enforcement is not necessarily a disadvantage (admittedly
slower though)
Many thx again + regards,
tge
On Wed, 2013-01-02 at 23:49 -0800, Jean-Sebastien Delfino wrote:
> On Sat, Dec 29, 2012 at 6:20 PM, Jean-Sebastien Delfino
> <js...@apache.org> wrote:
> Hi all,
>
>
> I had a few more offline Q&A exchanges with Thomas, and
> thought it'd be useful to share a summary here:
>
>
> Q: In the C++ trunk, is DataObject now replaced by
> tuscany::value and tuscany::list?
>
>
> A: Yes
>
>
>
>
> BTW I just committed a number of changes I made over the holidays,
> including some improvements to tuscany::value and tuscany::list, in
> particular to work with lists, nested lists and trees of key/value
> pairs (aka associations) as well as some minor improvements to handle
> comparisons of floating point number values.
>
>
> - Jean-Sebastien
Re: Porting Tuscany C++ to C++11 and some code cleanup
Posted by Jean-Sebastien Delfino <js...@apache.org>.
On Sat, Dec 29, 2012 at 6:20 PM, Jean-Sebastien Delfino <
jsdelfino@apache.org> wrote:
> Hi all,
>
>
> I had a few more offline Q&A exchanges with Thomas, and thought it'd be
> useful to share a summary here:
>
>
> Q: In the C++ trunk, is DataObject now replaced by tuscany::value
> and tuscany::list?
>
>
> A: Yes
>
>
>
BTW I just committed a number of changes I made over the holidays,
including some improvements to tuscany::value and tuscany::list, in
particular to work with lists, nested lists and trees of key/value pairs
(aka associations) as well as some minor improvements to handle comparisons
of floating point number values.
- Jean-Sebastien
Re: Porting Tuscany C++ to C++11 and some code cleanup
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Hi all,
I had a few more offline Q&A exchanges with Thomas, and thought it'd be
useful to share a summary here:
Q: In the C++ trunk, is DataObject now replaced by tuscany::value
and tuscany::list?
A: Yes
Q: Why are most files in kernel/ C++ header files?
A: They’re C++ templates that you can just include, similar to what other
C++ frameworks like boost do for example.
Q: In M3 a C++ component implementation looked like this:
virtual commonj::sdo::DataObjectPtr /*AccountReport*/
getAccountReport(const string customerID) {
...
}
What does a C++ component implementation look like with the code in trunk?
A: With trunk, a C++ component implementation must contain this function:
const value apply(const list<value>& params) {
// implement your own dispatch code here, for example
// if first element of params is “getAccountReport” then
// call your own getAccountReport function, which could look like
// const value getAccountReport(const value customerID)
}
The apply() function is a component invocation dispatch mechanism. It
shouldn’t be too difficult to provide a tool to generate the body of
apply() from a WSDL+XSD to lift the programming model to a level of
abstraction close to M3.
I was initially planning to do that but then found that writing apply() by
hand was good enough for me. I'm not sure about the value of requiring an
app developer to write a WSDL+XSD, use a tool to generate code, link with
that code, understand the additional moving parts and data conversion etc,
just to avoid having to write that apply() function... but if somebody
wants to do it, I can try to help integrate that support.
Q: Is the runtime implemented as Apache HTTPD modules?
A: Yes, the runtime plugs into Apache HTTPD as a set of HTTPD modules but
it should be possible to integrate with other servers too.
Q: Are C++ component implementations packaged as dynamic libraries?
A: Yes, the runtime also supports other component implementation
technologies and languages incl. Python, OpenCL C99 (for GPU programming),
Java (experimental) and a subset of MIT Scheme (useful for self-contained
testing).
Q: Which communication protocols are supported?
A: REST Web services using XML, ATOM, RSS or JSON over HTTP, and JSON-RPC.
Communication with SOAP services is supported using a configurable SCA
component wrapping Axis2/C in components/webservice/.
Q: Which versions of SCA are implemented?
M3 implements a subset of the OSOA (pre-OASIS) SCA assembly spec and a
subset of the corresponding SCA C++ component implementation spec.
Trunk implements a subset of the OASIS SCA assembly spec. The C++ component
implementation model is different from the spec, but like I said above it
shouldn't be too difficult to generate C++ implementations as per the spec
on top of the current dispatch mechanism.
Hope that helps.
- Jean-Sebastien
On Wed, Dec 19, 2012 at 1:00 PM, Thomas Gentsch <tg...@e-tge.de> wrote:
>
> Hi JS,
>
> I'm still looking through the docs, code, etc. I can find.
>
> One thing I discovered: it does not look to me as if SDO support has
> been removed from Java SCA, at least I found some related activity in
> 2011:
>
> http://www.mail-archive.com/user@tuscany.apache.org/msg03435.html
>
> http://www.mail-archive.com/dev@tuscany.apache.org/msg17116.html
>
> (the latter is quite funny because I actually submitted this against C++
> but seems as if the same problem occurred with Java? :-)
>
> More later ... :-)
> Rgds,
> tge
>
> On Thu, 2012-12-06 at 01:04 -0800, Jean-Sebastien Delfino wrote:
> > On Fri, Nov 30, 2012 at 9:43 AM, Thomas Gentsch <tg...@e-tge.de> wrote:
> >
> > OK, many thx for this info!
> >
> > Regarding SDO - yes, I noticed that there was not a lot of
> > activity
> > during the last years.
> > Hello out there: Is there anybody else still using this?
> >
> > Rgd SDO as SCA-internal data-flow mechanism - what is being
> > used now?
> > I know about libxml2 (actually its being used in SCA/SDO :-),
> > nothing
> > yet about JSON, will read.
> >
> >
> > Hi Thomas,
> >
> >
> > Here's a short overview of what's used now.
> >
> >
> > Data read/write functions are provided for XML (using Libxml2 [1]),
> > JSON (using Mozilla SpiderMonkey but I've started to migrate to
> > Jansson [2]), and Lisp/Scheme S-expressions [3].
> >
> >
> > Here's how to read XML in a C++ component:
> > <customer
> > age="21"><name>johndoe</name><phone>(650)123-4567</phone><phone>
> (415)765-4321</phone></customer>
> >
> >
> > // A list of strings containing the above XML doc, obtained from an
> > input stream for example
> > const list<string> ls = ...;
> >
> >
> > // Read the XML doc (the failable<...> result type helps encapsulate
> > error handling)
> > // See below for a description of the 'value' data type
> > const failable<value> fe = xml::readElements(ls);
> >
> >
> > // Assuming no failure, get and print the result
> > const value e = content(fe);
> > cout << e << endl;
> >
> >
> > The result is a list like follows (using the S-expression syntax here
> > for conciseness: element, customer, attribute, age are symbols, 21 is
> > a number, "johndoe" is a string, (x y) is a list of x, y):
> > ((element customer (attribute age "21") (element name "johndoe")
> > (element phone "(650)123-4567") (element phone "(415)765-4321")))
> >
> >
> > The runtime is schema-less. You do not need an XML schema to
> > read/write any XML.
> >
> >
> > If you don't care about the XML element vs attribute representation
> > you can strip it like this:
> > const value v = elementsToValues(e);
> > to get this:
> > ((customer (@age "21") (name "johndoe") (phone ("(650)123-4567"
> > "(415)765-4321"))))
> >
> >
> > Note the @age attribute name, which follows the Badgerfish [4]
> > convention often used to name XML attributes in JSON documents for
> > example.
> >
> > The same data can be constructed and represented in the various
> > programming languages supported by the runtime, as follows:
> >
> >
> > C++:
> > list<value>(list<value>("customer", list<value>("@age", 21),
> > list<value>("name", string("johndoe")), list<value>("phone",
> > list<value>("(650)123-4567", "(415)765-4321"))));
> > using the following C++ types:
> > - string, similar to std::string but lighter and faster for small
> > strings, with builtin conversions from/to native char*;
> > - list<T>, a lightweight list/lazy-list type with useful
> > Lisp/Scheme-like [5] functions incl. cons, car, cdr, map, filter,
> > reduce, assoc, etc;
> > - lambda<R(P...)>, a function type similar to std::function but
> > lighter and faster;
> > - value, a dynamic value type (type can be number, boolean, symbol,
> > string, list<value>, lambda<value(list<value>)>, value*) with builtin
> > conversions from/to native double, bool, char*, C++ lambdas and
> > pointers.
> >
> >
> > Python:
> > ((customer, ("'@age" 21), ("'name", "johndoe") (phone,
> > ("(650)123-4567" "(415)765-4321"))),)
> > using Python tuples [6] and native Python data types for strings,
> > numbers and booleans.
> >
> >
> > JavaScript / JSON:
> >
> {"customer":{"@age":"21","name":"johndoe","phone":["(650)123-4567","(415)765-4321"]}}
> > using JSON arrays and native Javascript types.
> >
> >
> > Scheme:
> > ((customer (@age "21") (name "johndoe") (phone ("(650)123-4567"
> > "(415)765-4321"))))
> > just an S-expression.
> >
> >
> > Java (there's experimental support for running Java components on the
> > C++ runtime):
> > list(list("'customer", list("'@age", 21), list("'name", "johndoe"),
> > list("'phone", list("(650)123-4567", "(415)765-4321"))));
> > using java.lang.Iterable [7] for lists and native Java data types for
> > strings, numbers and booleans (the list(...) function is a static
> > 'builder' function returning a java.lang.Iterable<?>.)
> >
> >
> > To summarize: fast and schemaless support for XML, JSON and
> > S-expressions, with lightweight representation using lists and simple
> > types in the supported programming languages.
> >
> >
> > Hope that helps.
> >
> >
> > [1] http://www.xmlsoft.org
> > [2] http://www.digip.org/jansson/
> > [3] http://en.wikipedia.org/wiki/S-expression
> > [4] http://badgerfish.ning.com
> > [5]
> http://www.gnu.org/software/mit-scheme/documentation/mit-scheme-ref/Lists.html#Lists
> > [6]
> http://docs.python.org/2/tutorial/datastructures.html#tuples-and-sequences
> > [7] http://docs.oracle.com/javase/6/docs/api/java/lang/Iterable.html
> >
> >
> > - Jean-Sebastien
>
>
>
Re: Porting Tuscany C++ to C++11 and some code cleanup
Posted by Thomas Gentsch <tg...@e-tge.de>.
Hi JS,
I'm still looking through the docs, code, etc. I can find.
One thing I discovered: it does not look to me as if SDO support has
been removed from Java SCA, at least I found some related activity in
2011:
http://www.mail-archive.com/user@tuscany.apache.org/msg03435.html
http://www.mail-archive.com/dev@tuscany.apache.org/msg17116.html
(the latter is quite funny because I actually submitted this against C++
but seems as if the same problem occurred with Java? :-)
More later ... :-)
Rgds,
tge
On Thu, 2012-12-06 at 01:04 -0800, Jean-Sebastien Delfino wrote:
> On Fri, Nov 30, 2012 at 9:43 AM, Thomas Gentsch <tg...@e-tge.de> wrote:
>
> OK, many thx for this info!
>
> Regarding SDO - yes, I noticed that there was not a lot of
> activity
> during the last years.
> Hello out there: Is there anybody else still using this?
>
> Rgd SDO as SCA-internal data-flow mechanism - what is being
> used now?
> I know about libxml2 (actually its being used in SCA/SDO :-),
> nothing
> yet about JSON, will read.
>
>
> Hi Thomas,
>
>
> Here's a short overview of what's used now.
>
>
> Data read/write functions are provided for XML (using Libxml2 [1]),
> JSON (using Mozilla SpiderMonkey but I've started to migrate to
> Jansson [2]), and Lisp/Scheme S-expressions [3].
>
>
> Here's how to read XML in a C++ component:
> <customer
> age="21"><name>johndoe</name><phone>(650)123-4567</phone><phone>(415)765-4321</phone></customer>
>
>
> // A list of strings containing the above XML doc, obtained from an
> input stream for example
> const list<string> ls = ...;
>
>
> // Read the XML doc (the failable<...> result type helps encapsulate
> error handling)
> // See below for a description of the 'value' data type
> const failable<value> fe = xml::readElements(ls);
>
>
> // Assuming no failure, get and print the result
> const value e = content(fe);
> cout << e << endl;
>
>
> The result is a list like follows (using the S-expression syntax here
> for conciseness: element, customer, attribute, age are symbols, 21 is
> a number, "johndoe" is a string, (x y) is a list of x, y):
> ((element customer (attribute age "21") (element name "johndoe")
> (element phone "(650)123-4567") (element phone "(415)765-4321")))
>
>
> The runtime is schema-less. You do not need an XML schema to
> read/write any XML.
>
>
> If you don't care about the XML element vs attribute representation
> you can strip it like this:
> const value v = elementsToValues(e);
> to get this:
> ((customer (@age "21") (name "johndoe") (phone ("(650)123-4567"
> "(415)765-4321"))))
>
>
> Note the @age attribute name, which follows the Badgerfish [4]
> convention often used to name XML attributes in JSON documents for
> example.
>
> The same data can be constructed and represented in the various
> programming languages supported by the runtime, as follows:
>
>
> C++:
> list<value>(list<value>("customer", list<value>("@age", 21),
> list<value>("name", string("johndoe")), list<value>("phone",
> list<value>("(650)123-4567", "(415)765-4321"))));
> using the following C++ types:
> - string, similar to std::string but lighter and faster for small
> strings, with builtin conversions from/to native char*;
> - list<T>, a lightweight list/lazy-list type with useful
> Lisp/Scheme-like [5] functions incl. cons, car, cdr, map, filter,
> reduce, assoc, etc;
> - lambda<R(P...)>, a function type similar to std::function but
> lighter and faster;
> - value, a dynamic value type (type can be number, boolean, symbol,
> string, list<value>, lambda<value(list<value>)>, value*) with builtin
> conversions from/to native double, bool, char*, C++ lambdas and
> pointers.
>
>
> Python:
> ((customer, ("'@age" 21), ("'name", "johndoe") (phone,
> ("(650)123-4567" "(415)765-4321"))),)
> using Python tuples [6] and native Python data types for strings,
> numbers and booleans.
>
>
> JavaScript / JSON:
> {"customer":{"@age":"21","name":"johndoe","phone":["(650)123-4567","(415)765-4321"]}}
> using JSON arrays and native Javascript types.
>
>
> Scheme:
> ((customer (@age "21") (name "johndoe") (phone ("(650)123-4567"
> "(415)765-4321"))))
> just an S-expression.
>
>
> Java (there's experimental support for running Java components on the
> C++ runtime):
> list(list("'customer", list("'@age", 21), list("'name", "johndoe"),
> list("'phone", list("(650)123-4567", "(415)765-4321"))));
> using java.lang.Iterable [7] for lists and native Java data types for
> strings, numbers and booleans (the list(...) function is a static
> 'builder' function returning a java.lang.Iterable<?>.)
>
>
> To summarize: fast and schemaless support for XML, JSON and
> S-expressions, with lightweight representation using lists and simple
> types in the supported programming languages.
>
>
> Hope that helps.
>
>
> [1] http://www.xmlsoft.org
> [2] http://www.digip.org/jansson/
> [3] http://en.wikipedia.org/wiki/S-expression
> [4] http://badgerfish.ning.com
> [5] http://www.gnu.org/software/mit-scheme/documentation/mit-scheme-ref/Lists.html#Lists
> [6] http://docs.python.org/2/tutorial/datastructures.html#tuples-and-sequences
> [7] http://docs.oracle.com/javase/6/docs/api/java/lang/Iterable.html
>
>
> - Jean-Sebastien
Re: Porting Tuscany C++ to C++11 and some code cleanup
Posted by Jean-Sebastien Delfino <js...@apache.org>.
On Fri, Nov 30, 2012 at 9:43 AM, Thomas Gentsch <tg...@e-tge.de> wrote:
>
> OK, many thx for this info!
>
> Regarding SDO - yes, I noticed that there was not a lot of activity
> during the last years.
> Hello out there: Is there anybody else still using this?
>
> Rgd SDO as SCA-internal data-flow mechanism - what is being used now?
> I know about libxml2 (actually its being used in SCA/SDO :-), nothing
> yet about JSON, will read.
>
Hi Thomas,
Here's a short overview of what's used now.
Data read/write functions are provided for XML (using Libxml2 [1]), JSON
(using Mozilla SpiderMonkey but I've started to migrate to Jansson [2]),
and Lisp/Scheme S-expressions [3].
Here's how to read XML in a C++ component:
<customer
age="21"><name>johndoe</name><phone>(650)123-4567</phone><phone>(415)765-4321</phone></customer>
// A list of strings containing the above XML doc, obtained from an input
stream for example
const list<string> ls = ...;
// Read the XML doc (the failable<...> result type helps encapsulate error
handling)
// See below for a description of the 'value' data type
const failable<value> fe = xml::readElements(ls);
// Assuming no failure, get and print the result
const value e = content(fe);
cout << e << endl;
The result is a list like follows (using the S-expression syntax here for
conciseness: element, customer, attribute, age are symbols, 21 is a number,
"johndoe" is a string, (x y) is a list of x, y):
((element customer (attribute age "21") (element name "johndoe") (element
phone "(650)123-4567") (element phone "(415)765-4321")))
The runtime is schema-less. You do not need an XML schema to read/write any
XML.
If you don't care about the XML element vs attribute representation you can
strip it like this:
const value v = elementsToValues(e);
to get this:
((customer (@age "21") (name "johndoe") (phone ("(650)123-4567"
"(415)765-4321"))))
Note the @age attribute name, which follows the Badgerfish [4] convention
often used to name XML attributes in JSON documents for example.
The same data can be constructed and represented in the various programming
languages supported by the runtime, as follows:
C++:
list<value>(list<value>("customer", list<value>("@age", 21),
list<value>("name", string("johndoe")), list<value>("phone",
list<value>("(650)123-4567", "(415)765-4321"))));
using the following C++ types:
- string, similar to std::string but lighter and faster for small strings,
with builtin conversions from/to native char*;
- list<T>, a lightweight list/lazy-list type with useful Lisp/Scheme-like
[5] functions incl. cons, car, cdr, map, filter, reduce, assoc, etc;
- lambda<R(P...)>, a function type similar to std::function but lighter and
faster;
- value, a dynamic value type (type can be number, boolean, symbol, string,
list<value>, lambda<value(list<value>)>, value*) with builtin conversions
from/to native double, bool, char*, C++ lambdas and pointers.
Python:
((customer, ("'@age" 21), ("'name", "johndoe") (phone, ("(650)123-4567"
"(415)765-4321"))),)
using Python tuples [6] and native Python data types for strings, numbers
and booleans.
JavaScript / JSON:
{"customer":{"@age":"21","name":"johndoe","phone":["(650)123-4567","(415)765-4321"]}}
using JSON arrays and native Javascript types.
Scheme:
((customer (@age "21") (name "johndoe") (phone ("(650)123-4567"
"(415)765-4321"))))
just an S-expression.
Java (there's experimental support for running Java components on the C++
runtime):
list(list("'customer", list("'@age", 21), list("'name", "johndoe"),
list("'phone", list("(650)123-4567", "(415)765-4321"))));
using java.lang.Iterable [7] for lists and native Java data types for
strings, numbers and booleans (the list(...) function is a static 'builder'
function returning a java.lang.Iterable<?>.)
To summarize: fast and schemaless support for XML, JSON and S-expressions,
with lightweight representation using lists and simple types in the
supported programming languages.
Hope that helps.
[1] http://www.xmlsoft.org
[2] http://www.digip.org/jansson/
[3] http://en.wikipedia.org/wiki/S-expression
[4] http://badgerfish.ning.com
[5]
http://www.gnu.org/software/mit-scheme/documentation/mit-scheme-ref/Lists.html#Lists
[6]
http://docs.python.org/2/tutorial/datastructures.html#tuples-and-sequences
[7] http://docs.oracle.com/javase/6/docs/api/java/lang/Iterable.html
- Jean-Sebastien
Re: Porting Tuscany C++ to C++11 and some code cleanup
Posted by Thomas Gentsch <tg...@e-tge.de>.
OK, many thx for this info!
Regarding SDO - yes, I noticed that there was not a lot of activity
during the last years.
Hello out there: Is there anybody else still using this?
Rgd SDO as SCA-internal data-flow mechanism - what is being used now?
I know about libxml2 (actually its being used in SCA/SDO :-), nothing
yet about JSON, will read.
Rgd updating SDO: If nobody else cares, then I'm happy with it for now,
so lets let it rest in peace ... (except that I'll have to deal with it
all by myself if I find any problems :-)
Rgds + nice WE,
tge
On Mon, 2012-11-26 at 23:13 -0800, Jean-Sebastien Delfino wrote:
> On Sun, Nov 25, 2012 at 1:31 PM, Thomas Gentsch <tg...@e-tge.de> wrote:
> On Sun, 2012-11-25 at 10:38 -0800, Jean-Sebastien Delfino
> wrote:
> > On Fri, Nov 23, 2012 at 9:02 AM, Thomas Gentsch
> <tg...@e-tge.de> wrote:
> ...
> > Great! Papers from the C++11 standard work groups are
> available on
> > open-std.org there [1]. The final ISO standard is not free
> but the
> > last draft [2] is free. If you just want a high level
> overview
> > there's one on Wikipedia [3]. Hope that helps.
>
>
> Shortly looked through it, definitely interesting. Of course
> that makes
> me worry a bit how far compilers support this already ...
> particularly
> as partially maybe (as in our case) older OS versions are to
> be
> supported.
>
>
> On Linux, GCC 4.3 and later, see [5]. On MacOS, CLang 3.1 and later,
> see [6].
> Of course you don't need to worry about it if you're using SDO as I'm
> not touching the M3 SDO code anyway :).
>
> ...
>
>
>
>
> I quickly looked into Jira and found at least these:
>
> https://issues.apache.org/jira/browse/TUSCANY-3841
> https://issues.apache.org/jira/browse/TUSCANY-3715
> https://issues.apache.org/jira/browse/TUSCANY-3597
>
> https://issues.apache.org/jira/browse/TUSCANY-1552
>
>
>
>
> Ah, I now realize that you're using SDO, and I was only looking for
> SCA JIRAs.
>
>
> >
> > The C++ trunk has already gone through some refactoring and
> quite a
> > few changes over time since M3... There's no SDO anymore
>
>
> Oh!!! Actually I always believed Tuscany is mainly about SDO!
> Well, then I have to correct myself - we are using Tuscany C++
> SDO. I
> wasn't aware of this at all (haven't looked into it for a
> while though)
>
>
> Tus-SCA-ny is mainly about SCA [7]. SCA is a programming model for
> building apps with components that provide or use services, and
> initially used SDO to represent (mostly XML) data flowing through
> these services.
>
>
>
> > (like the Java trunk, which I believe dropped SDO as well),
> the
> > composite files use the new SCDL from OASIS, the runtime
> integrates
> > with Apache HTTPD, etc. There's still an integration with
> Axis2C but
> > I've not looked at it for a very long time.
> >
> >
> > So, if you're still using SDO you'll probably want to stick
> to the M3
> > level, but I can help apply your patch to a maintenance
> branch off M3
> > at some point if that helps.
>
>
> Well, if SDO is dead anyway then there will not be any release
> anymore I
> suppose, so maybe no need to bother.
>
>
> ...
>
>
> I'm not sure about the state of SDO. I've not seen any activity on it
> for some time now, and I'm not planning to do anything with SDO at
> this point, but can try to help on my spare time if you or others are
> interested in maintaining or evolving the SDO code.
>
>
>
>
> OK, then I should look into the alternatives? Is there any
> replacement?
> Many thx + regards,
>
>
>
> I personally like libxml2 [8] for XML and jansson [9] for JSON, and
> there's several other good XML and JSON libraries out there too, but
> if SDO works for you and you have a good handle on that code (and it
> looks like it since you were able to create some good patches), then
> why change? :)
>
> >
> > [1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/
> > [2]
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3242.pdf
> > [3] http://en.wikipedia.org/wiki/C%2B%2B11
> > [4] https://issues.apache.org/jira/browse/TUSCANY-3598
>
>
> [5] http://gcc.gnu.org/projects/cxx0x.html
> [6] http://clang.llvm.org/cxx_status.html
> [7] http://www.oasis-opencsa.org/committees
> [8] http://www.xmlsoft.org
> [9] http://www.digip.org/jansson/
>
>
Re: Porting Tuscany C++ to C++11 and some code cleanup
Posted by Jean-Sebastien Delfino <js...@apache.org>.
On Sun, Nov 25, 2012 at 1:31 PM, Thomas Gentsch <tg...@e-tge.de> wrote:
> On Sun, 2012-11-25 at 10:38 -0800, Jean-Sebastien Delfino wrote:
> > On Fri, Nov 23, 2012 at 9:02 AM, Thomas Gentsch <tg...@e-tge.de> wrote:
>
...
>
> Great! Papers from the C++11 standard work groups are available on
> > open-std.org there [1]. The final ISO standard is not free but the
> > last draft [2] is free. If you just want a high level overview
> > there's one on Wikipedia [3]. Hope that helps.
>
> Shortly looked through it, definitely interesting. Of course that makes
> me worry a bit how far compilers support this already ... particularly
> as partially maybe (as in our case) older OS versions are to be
> supported.
>
On Linux, GCC 4.3 and later, see [5]. On MacOS, CLang 3.1 and later, see
[6].
Of course you don't need to worry about it if you're using SDO as I'm not
touching the M3 SDO code anyway :).
...
> I quickly looked into Jira and found at least these:
>
> https://issues.apache.org/jira/browse/TUSCANY-3841
> https://issues.apache.org/jira/browse/TUSCANY-3715
> https://issues.apache.org/jira/browse/TUSCANY-3597
>
> https://issues.apache.org/jira/browse/TUSCANY-1552
>
>
Ah, I now realize that you're using SDO, and I was only looking for SCA
JIRAs.
>
> >
> > The C++ trunk has already gone through some refactoring and quite a
> > few changes over time since M3... There's no SDO anymore
>
> Oh!!! Actually I always believed Tuscany is mainly about SDO!
> Well, then I have to correct myself - we are using Tuscany C++ SDO. I
> wasn't aware of this at all (haven't looked into it for a while though)
>
Tus-SCA-ny is mainly about SCA [7]. SCA is a programming model for building
apps with components that provide or use services, and initially used SDO
to represent (mostly XML) data flowing through these services.
> > (like the Java trunk, which I believe dropped SDO as well), the
> > composite files use the new SCDL from OASIS, the runtime integrates
> > with Apache HTTPD, etc. There's still an integration with Axis2C but
> > I've not looked at it for a very long time.
> >
> >
> > So, if you're still using SDO you'll probably want to stick to the M3
> > level, but I can help apply your patch to a maintenance branch off M3
> > at some point if that helps.
>
> Well, if SDO is dead anyway then there will not be any release anymore I
> suppose, so maybe no need to bother.
>
> ...
I'm not sure about the state of SDO. I've not seen any activity on it for
some time now, and I'm not planning to do anything with SDO at this point,
but can try to help on my spare time if you or others are interested in
maintaining or evolving the SDO code.
> OK, then I should look into the alternatives? Is there any replacement?
> Many thx + regards,
>
I personally like libxml2 [8] for XML and jansson [9] for JSON, and there's
several other good XML and JSON libraries out there too, but if SDO works
for you and you have a good handle on that code (and it looks like it since
you were able to create some good patches), then why change? :)
> >
> > [1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/
> > [2] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3242.pdf
> > [3] http://en.wikipedia.org/wiki/C%2B%2B11
> > [4] https://issues.apache.org/jira/browse/TUSCANY-3598
>
> [5] http://gcc.gnu.org/projects/cxx0x.html
[6] http://clang.llvm.org/cxx_status.html
[7] http://www.oasis-opencsa.org/committees
[8] http://www.xmlsoft.org
[9] http://www.digip.org/jansson/
Re: Porting Tuscany C++ to C++11 and some code cleanup
Posted by Thomas Gentsch <tg...@e-tge.de>.
On Sun, 2012-11-25 at 10:38 -0800, Jean-Sebastien Delfino wrote:
> On Fri, Nov 23, 2012 at 9:02 AM, Thomas Gentsch <tg...@e-tge.de> wrote:
>
> Hi JS + all,
>
> we are using Tuscany C++ in one of our projects, hence we/I
> have some
> personal interest and also would like to contribute, if
> possible.
>
> Tbh, I don't know details about C++11 (will read a bit) nor
> the other
> things you mention.
>
>
> Great! Papers from the C++11 standard work groups are available on
> open-std.org there [1]. The final ISO standard is not free but the
> last draft [2] is free. If you just want a high level overview
> there's one on Wikipedia [3]. Hope that helps.
Shortly looked through it, definitely interesting. Of course that makes
me worry a bit how far compilers support this already ... particularly
as partially maybe (as in our case) older OS versions are to be
supported.
> One thing though which appears quite important to me is that
> the various
> patches we/I have done (most/all (?) submitted to Jira) and
> other people
> are incorporated into the general code so that they are in the
> next
> release if there will ever be one ... and of course this is
> easier
> before any refactorings.
>
>
> I found one JIRA with a patch from you [4], which looks like a change
> to the SDO + Axiom support in the SCA-Native-M3 release.
I quickly looked into Jira and found at least these:
https://issues.apache.org/jira/browse/TUSCANY-3841
https://issues.apache.org/jira/browse/TUSCANY-3715
https://issues.apache.org/jira/browse/TUSCANY-3597
https://issues.apache.org/jira/browse/TUSCANY-1552
>
> The C++ trunk has already gone through some refactoring and quite a
> few changes over time since M3... There's no SDO anymore
Oh!!! Actually I always believed Tuscany is mainly about SDO!
Well, then I have to correct myself - we are using Tuscany C++ SDO. I
wasn't aware of this at all (haven't looked into it for a while though)
> (like the Java trunk, which I believe dropped SDO as well), the
> composite files use the new SCDL from OASIS, the runtime integrates
> with Apache HTTPD, etc. There's still an integration with Axis2C but
> I've not looked at it for a very long time.
>
>
> So, if you're still using SDO you'll probably want to stick to the M3
> level, but I can help apply your patch to a maintenance branch off M3
> at some point if that helps.
Well, if SDO is dead anyway then there will not be any release anymore I
suppose, so maybe no need to bother.
>
> The other thing: Are the planned changes going to modify the
> API
> interface or is it just internally?
>
>
> The C++11 changes only apply to the runtime internals, but again if
> you're using the SDO-based API from M3, that already changed a long
> time ago.
OK, then I should look into the alternatives? Is there any replacement?
Many thx + regards,
tge
>
> Rgds,
> tge
>
>
>
>
> [1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/
> [2] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3242.pdf
> [3] http://en.wikipedia.org/wiki/C%2B%2B11
> [4] https://issues.apache.org/jira/browse/TUSCANY-3598
Re: Porting Tuscany C++ to C++11 and some code cleanup
Posted by Jean-Sebastien Delfino <js...@apache.org>.
On Fri, Nov 23, 2012 at 9:02 AM, Thomas Gentsch <tg...@e-tge.de> wrote:
>
> Hi JS + all,
>
> we are using Tuscany C++ in one of our projects, hence we/I have some
> personal interest and also would like to contribute, if possible.
> Tbh, I don't know details about C++11 (will read a bit) nor the other
> things you mention.
>
Great! Papers from the C++11 standard work groups are available on
open-std.org there [1]. The final ISO standard is not free but the last
draft [2] is free. If you just want a high level overview there's one on
Wikipedia [3]. Hope that helps.
> One thing though which appears quite important to me is that the various
> patches we/I have done (most/all (?) submitted to Jira) and other people
> are incorporated into the general code so that they are in the next
> release if there will ever be one ... and of course this is easier
> before any refactorings.
>
I found one JIRA with a patch from you [4], which looks like a change to
the SDO + Axiom support in the SCA-Native-M3 release.
The C++ trunk has already gone through some refactoring and quite a few
changes over time since M3... There's no SDO anymore (like the Java trunk,
which I believe dropped SDO as well), the composite files use the new SCDL
from OASIS, the runtime integrates with Apache HTTPD, etc. There's still an
integration with Axis2C but I've not looked at it for a very long time.
So, if you're still using SDO you'll probably want to stick to the M3
level, but I can help apply your patch to a maintenance branch off M3 at
some point if that helps.
>
> The other thing: Are the planned changes going to modify the API
> interface or is it just internally?
>
The C++11 changes only apply to the runtime internals, but again if you're
using the SDO-based API from M3, that already changed a long time ago.
>
> Rgds,
> tge
>
>
[1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/
[2] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3242.pdf
[3] http://en.wikipedia.org/wiki/C%2B%2B11
[4] https://issues.apache.org/jira/browse/TUSCANY-3598
Re: Porting Tuscany C++ to C++11 and some code cleanup
Posted by Thomas Gentsch <tg...@e-tge.de>.
Hi JS + all,
we are using Tuscany C++ in one of our projects, hence we/I have some
personal interest and also would like to contribute, if possible.
Tbh, I don't know details about C++11 (will read a bit) nor the other
things you mention.
One thing though which appears quite important to me is that the various
patches we/I have done (most/all (?) submitted to Jira) and other people
are incorporated into the general code so that they are in the next
release if there will ever be one ... and of course this is easier
before any refactorings.
The other thing: Are the planned changes going to modify the API
interface or is it just internally?
Rgds,
tge
On Thu, 2012-11-22 at 11:31 -0800, Jean-Sebastien Delfino wrote:
> Hi all,
>
>
> Happy Thanksgiving :). I'm going to have a little bit of spare time on
> the long weekend to do some cleanup of Tuscany C++.
>
>
> I'm planning to do some code refactoring to start leveraging some of
> the new C++11 standard constructs (replace the current functors with C
> ++11 lambda expressions for example). I'll also try to do some more
> general cleanup of the code base and improvements to a few areas like
> the JSON support (which currently requires SpiderMonkey, that's
> overkill) and the server hosting module.
>
>
> These changes should simplify the code base a bit and bring
> significant performance improvements as well. It'd be nice to have
> another release at some point... perhaps on one of the next holiday
> breaks if I get enough spare time again, or if others would like to
> help...
>
>
> HTH
>
>
> - Jean-Sebastien