PocoCapsule current Status
seas seas
with some other product?
What is about whole idea of IoC for C++? If PocoCapsule is not
evolving, is it because IoC was considered not useful for C++, unsafe,
other patterns appeared or something else?
As far as I understand there are 2-3, maybe few more products that
implement IoC for C++ available and
PocoCapsule is the most mature of them.
I see several disadvantages in current version (as I see it's 1.1 from
google code):
1. No separate namespace.
2. Header files are required to be right in INCLUDE folder - better to
place them in subfolder.
3. Generation Tools depend on Java.
4. No static linking libraries are built by default.
5. Cannot generate source code out of setup.xml for compilation and
link with my app if I don't need reconfiguration feature.
Does anybody have the same thoughts? Does anybody work on something of
this list? Are there any barriers to start working, like patents?
Thanks for sharing your thoughts.
Regards,
Andrey
Ke Jin
Thanks for you questions. See inline responses.
Ke
On Mar 19, 4:20 am, seas seas <seasm...@gmail.com> wrote:
> What is PocoCapsule current status? Is it evolving?
Yes!
> Has it been forked with some other product?
No idea.
> What is about whole idea of IoC for C++?
Should be explained in various documents and articles. Any specific
question beyond them?
> If PocoCapsule is not evolving, is it because IoC was considered not useful for C++, unsafe,
> other patterns appeared or something else?
I don't think so.
> As far as I understand there are 2-3, maybe few more products that
> implement IoC for C++ available and PocoCapsule is the most mature of them.
>
> I see several disadvantages in current version (as I see it's 1.1 from google code):
> 1. No separate namespace.
Please elaborate. Why this is such a big issue as a "disadvantage"?
AFAIK, namespec serve for two purposes:
a. avoid name collision.
b. have code easily readable (it give direct indication on where an
involved symbol comes from).
Neither of these two issues are concerns for PocoCapsule. First,
PocoCapsule have only a few exported symbols and all of them are
prefixed with POCO_. If this not guaranteed no name collision, then,
an namespec would not either. Secondly, in typical cases, PocoCapsule
exported API calls are not suppose to be spread throughout an
application. Therefore, code readability isn't an issue.
> 2. Header files are required to be right in INCLUDE folder - better to place them in subfolder.
There is no such restriction. In fact, PocoCapsule doesn't care the
header file locations because it does even open/access them. It is C++
pre-compiler open them and care their location.
> 3. Generation Tools depend on Java.
Why this is an issue?
> 4. No static linking libraries are built by default.
If you mean PocoCapsule's runtime library (i.e. libpococapsule.so/
pococapsule.dll), then, this isn't a big deal. We can have our make
file to generate corresponded static libraries. You should be also
able to do it by slightly modify the make file.
If you mean proxy's library, then, it isn't an issue. PocoCapsule
doesn't even build proxy libraries by default. It is users'
responsibility to build them and their choice to build them to dynamic
or static library.
> 5. Cannot generate source code out of setup.xml for compilation and
> link with my app if I don't need reconfiguration feature.
>
If we do provide such XML to C++ converting, the C++ code would simply
be something to create a DOM tree C++ object in memory with calls to
create root node, create child nodes, add child nodes, etc.:
So, we decided to take a much better approach. Namely, instead of
generating code that create the DOM tree, we generate the DOM tree
itself. This feature is documented in user guide section 2.3.2
briefly. Namely, the encoded string generated from pxencode is already
a representation of such in memory DOM tree. to use it, you can simply
embed this string in your code as:
const char* descriptor = ".....";
POCO::AppContext ctxt = POCO::AppContext::create(descriptor,
"string");
> Does anybody have the same thoughts? Does anybody work on something of
> this list? Are there any barriers to start working, like patents?
>
You mean patents of using a IoC container or patents in detail/
specific solutions on implement a IoC container? There are tons of
patents in building a car, do they prevent us to drive our cars?
Ke Jin
I have a few more thoughts/points on some of your questions after
previous response. See my inline answers.
Regards,
Ke
On Mar 19, 4:20 am, seas seas <seasm...@gmail.com> wrote:
> What is PocoCapsule current status? Is it evolving? Has it been forked
> with some other product?
> What is about whole idea of IoC for C++? If PocoCapsule is not
> evolving, is it because IoC was considered not useful for C++, unsafe,
> other patterns appeared or something else?
>
> As far as I understand there are 2-3, maybe few more products that
> implement IoC for C++ available and
> PocoCapsule is the most mature of them.
>
> I see several disadvantages in current version (as I see it's 1.1 from
> google code):
> 1. No separate namespace.
> 2. Header files are required to be right in INCLUDE folder - better to
> place them in subfolder.
>
Reading your question again, I realized what you meant here was that
you wants to organize your header files in Java class alike sub-
directories by C++ namespace names. For instance, the header for class
MyNameSpace::MyClass is going to be placed in the MyNameSpace
subdirectory (i.e. its full path should be <INCLUDE>/MyNameSpece/
MyClass.h).
First of all, PocoCapsule does not prohibit one to take this practice.
As said in my previous followup answer, PocoCapsule doesn't even care
where header files are placed, because it doesn't even access these
header files. If one does take this Java alike practice, what he/she
needs to figure out is how to let the C++ compiler (actually its pre-
processor) to search into those sub-directories by enumerating all of
them in headre file search directory setting (such as using multiple -
I<dir> compiler command line options), or have them hard coded in
source code (i.e. #include <MyNameSpece/MyClass.h> instead of simply
#include <MyClass.h>). Either of these two approach is annoying. I
don't see the advantage of having such sub-directory in the first
place.
One may further suggest to solve this problem by specifying the header
file locations in the deployment setup.xml file as if they were java
classes .java files, for instance as:
<bean class="MyClass" header="MyNameSpace/MyHeader.h"/>
This design is used by OASIS's SCA WebServices component container's C+
+ mapping. It appears to be cool and natural to programmers from Java
world but will immediately encounter problems for large or even
moderated C++ applications (there are at least four problems with this
design, easily see by any C++ professional). Doubltlessly, the SCA (at
least its C++ mapping) is a poor design-by-committee spec and never
flies for large/moderated C++ applications (see my article about
PocoCapsule for WebServices for detail).
In summary, although the idea of having C++ header file been placed in
subdirectories named by their NameSpaces appears to be cool and
natural to programmers come from Java background originally, it is
considered a bad and harmful practice for C++ applications in general
and is commonly avoided by C++ professionals.
>
> 5. Cannot generate source code out of setup.xml for compilation and
> link with my app if I don't need reconfiguration feature.
>
Now, I realize what you meant was a CASE tool alike code generation
that not merely generates proxies from the setup.xml but generates
actual C++ imperative
procedures with hardcoded parameters and dependency and execution (and
even library loading) order and conditional logic to setup the
application.
First of all, we have no intention to build PocoCapsule as another
CASE tool for C++. CASE tools, a popular movement two decades ago, has
already turned out
to be a failure and already abandoned by the industry for years.
Although PocoCapsule does not prevent itself to be used as a CASE tool
if one like, it is designed more importantly and most likely to be
used as a component container. A component container allows loading/
wiring/configuring logic to be deferred till on-field deployment time
or even runtime. It also allow these logic to be manipulated/
analysized by domain users without applying/diagnosizing code
compilation. CASE tools, on the other hand, assumes such wiring/
configuring and even loading order knowledges are provided/fixed at
development time and need to be manipulated by low level developers
and involving C++ compilers.
Secondly, as answered previously and documented by PocoCapsule user
guide (section 2.3), PocoCapsule does provide the CASE tool alike
feature you are looking for. This feature not only allows one to embed
the loading/wiring/configuring logic in the application executable
(that avoids such logic to be deleted or changed) but also eliminates
the needs and runtime cost (cpu and memory) of XML handling.
Unlike traditional CASE tools, PocoCapsule does not generate the error-
prone and vulnerable imperative-command-driven C++ code to setup the
application in this usage. Instead, PocoCapsule generates the data-
driven C++ code, conceptually much like the table driven paser's C
code generated from YACC. The data, in a C++ table structure, as
mentioned in the previous followup, driectly maps the DOM tree in
memory (hence, completely eliminated the needs of further XML
parsing). This approach is not only much error-proof comparing to
generating imperative-command-code but also supports hybrid usage
scenario (e.g. initial configuration is in generated embedded hardcode
but still could be reconfigured through on-field/runtime XML).
>
> Does anybody have the same thoughts? Does anybody work on something of
> this list? Are there any barriers to start working, like patents?
>
To summarize, PocoCapsule has no intention to simply mimic Java in C+
+. As said, although such a mimic appears to be cool and an advantage,
it is a poor and
harmful practice largely avoided by C++ professionals. Also,
PocoCapsule has no intention to be a CASE tool. Although you listed
this kind of CASE tool alike feature as an advantage, based on more
than a decade of experience and observation in various enterprise
level C++ products/applications (such as CORBA and
WebServices since 1996 and as an C++ ORB, OTS, Event etc COS
development lead/architect since 2000) and component/modeling
frameworks (such as CCM and MDA since 2000), my opinion is that such a
CASE tool alike feature will no longer be interested by either
industry (commerical) or the community (open source) beyond a few
academic ivory towers.
Best regards,
Ke
seas seas
Thanks for your answers. Also answered you inline below:
I was rather talking about easy reading. Yes, you are right, current
implementation cause no problems.
> > 2. Header files are required to be right in INCLUDE folder - better to place them in subfolder.
>
> There is no such restriction. In fact, PocoCapsule doesn't care the
> header file locations because it does even open/access them. It is C++
> pre-compiler open them and care their location.
Yes, you are right - we can always point the compiler to the right
place, but most, available with the source code, projects support
autotools service with "configure" script, where we define "--prefix"
and later install headers/libs somewhere in /usr in case of linux or
other folder of our choice. In case of simple projects, this becomes
convenient for build infrastructure preparation - just define INCLUDE=/
usr/include and get all header files. The same structure is supported
in majority of installation packages for linux - they all support "/
usr/include, /usr/lib" structure. I was looking other packages like
xercesc, boost, log4cplus, etc. All they store their headers in
subfolder, keeping /usr/include in order. Order has it's own benefits
- one easily can understand which header files are related to
particular library. If multiple library headers are stored in the same
folder (i.e. right in /usr/include) - hard to understand what is
where. As a resume - having a subfolder is convenient, and probably,
supporting best practices (mimic other open source libraries) will
ease putting pococapsule into linux repositories. I understand, that
the only point where header files used in pococapsule - is entrance-
point (main() function source).
> > 3. Generation Tools depend on Java.
>
> Why this is an issue?
Not a big issue, but having a huge java sdk somewhere by, taking into
account that most likely one's whole idea is getting rid of it in the
project (otherwise, why writing in C++) - looks strange. I simply
found my project build infrastructure becoming dependent on too many
environment settings, while I would like to build it "to work right
out of the box". It's just a convenience - to have tools that don't
require anything else. I played with CodeSynthesis XSD just before -
it's a nice product, easy to use, while the underlying implementation
is quite complex. Since it's XML/XSD - they could also build it with
Java (benefiting from excellent Java XML support), but for some reason
they didn't.
> > 4. No static linking libraries are built by default.
>
> If you mean PocoCapsule's runtime library (i.e. libpococapsule.so/
> pococapsule.dll), then, this isn't a big deal. We can have our make
> file to generate corresponded static libraries. You should be also
> able to do it by slightly modify the make file.
Yes, I did it. Why not to include it into official package 'by
default'?
> If you mean proxy's library, then, it isn't an issue. PocoCapsule
> doesn't even build proxy libraries by default. It is users'
> responsibility to build them and their choice to build them to dynamic
> or static library.
Yes, that's clear. I was asking about libpococapsule.so library. My
idea is to build a single-executable application, in order to save on
deployment issues - application deployment is not very easy issue for C
++ world and my project is not yet so big to dig into this area.
That's why I am trying to link everything statically.
> > 5. Cannot generate source code out of setup.xml for compilation and
> > link with my app if I don't need reconfiguration feature.
>
> If we do provide such XML to C++ converting, the C++ code would simply
> be something to create a DOM tree C++ object in memory with calls to
> create root node, create child nodes, add child nodes, etc.:
>
> So, we decided to take a much better approach. Namely, instead of
> generating code that create the DOM tree, we generate the DOM tree
> itself. This feature is documented in user guide section 2.3.2
> briefly. Namely, the encoded string generated from pxencode is already
> a representation of such in memory DOM tree. to use it, you can simply
> embed this string in your code as:
>
> const char* descriptor = ".....";
>
> POCO::AppContext ctxt = POCO::AppContext::create(descriptor,
> "string");
Using inlined configuration is really an option for me - I am using
it. But I was rather talking about two other things:
1. I like the idea of XML and the whole easy format of bean wiring
file, but I would like to keep it in a separate file (inline it into C+
+ source will require either implement XML processing in the
application or will prevent me from using XSD, DSM/XSLT). Inlining it
dynamically into source code during build can be quite difficult task,
but also possible.
2. I would like to benefit from C++ static type verification at
compile-time. Since type-safety of relations between beans in XML is
not checked, or at least it's not so easy to implement (believe it's
possible through DSM and XSD). Further than this, I don't need
reconfiguration - only pure IoC, just not to hardcode all relations
and extract initialization outside of my logic, relying on some well
established generator - relying on pococapsule in my case. And again,
I would like to build a single executable without setup.xml somewhere
by.
> > Does anybody have the same thoughts? Does anybody work on something of
> > this list? Are there any barriers to start working, like patents?
>
> You mean patents of using a IoC container or patents in detail/
> specific solutions on implement a IoC container? There are tons of
> patents in building a car, do they prevent us to drive our cars?
>
> > Thanks for sharing your thoughts.
> > Regards,
> > Andrey
All I mentioned are not disadvantages, but rather points for
improvement - I just used the wrong word.
Thanks for your time.
Regards,
Andrey
seas seas
PocoCapsule shouldn't mimic Java, I agree. As I explained earlier,
subfolder should just separate pococapsule headers from other library
headers. This trivial evolution leverage clarity and ease of use.
Besides this, looks like it's a best practice and widely used among
open-source projects (boost, xercesc, codesynthesis xsd, log4cplus,
etc). No additional fields specifying header file are required,
setup.xml should know nothing about header files, only types.
As far as I understand, code generation is still in use - one of the
best examples I found recently, already mentioned CodeSynthesis XSD.
Probably, I misunderstand what you mean saying CASE tool - for me it's
something huge with GUI and only a little coding. Instead I only
thought about some small C++ generator, that could implement static
bean wiring mechanism, defined in setup.xml and employ C++ compile-
time types verification. Also benefiting with initialization speedup,
independence of any XML or other parsing libraries and ability to
single-executable easy creation (relying all the complexity to the
generator tool).
But the major benefit from all above - of course type verification.
From my point of view, IoC is an excellent pattern. It decouples logic
inside application from each other. This opens the way to extensive
unit-testing. And this means, IoC can be used as a pure design pattern
without dynamic configuration feature. And that is highly desired.
>
> Best regards,
> Ke
Regards,
Andrey
Ke Jin
Really appreciate your followup on my previous answers :) This implies
you are indeed serious. Many thanks!
See my inline comments. To keep the post in a readable length, I cut
out issues that have already cleared or non-critical.
Ke
On Mar 22, 3:19 pm, seas seas <seasm...@gmail.com> wrote:
> > > 2. Header files are required to be right in INCLUDE folder - better to place them in subfolder.
>
> > There is no such restriction. In fact, PocoCapsule doesn't care the
> > header file locations because it does even open/access them. It is C++
> > pre-compiler open them and care their location.
>
> Yes, you are right - we can always point the compiler to the right
> place, but most, available with the source code, projects support
> autotools service with "configure" script, where we define "--prefix"
> and later install headers/libs somewhere in /usr in case of linux or
> other folder of our choice. In case of simple projects, this becomes
> convenient for build infrastructure preparation - just define INCLUDE=/
> usr/include and get all header files. The same structure is supported
> in majority of installation packages for linux - they all support "/
> usr/include, /usr/lib" structure. I was looking other packages like
> xercesc, boost, log4cplus, etc. All they store their headers in
> subfolder, keeping /usr/include in order. Order has it's own benefits
> - one easily can understand which header files are related to
> particular library. If multiple library headers are stored in the same
> folder (i.e. right in /usr/include) - hard to understand what is
> where. As a resume - having a subfolder is convenient, and probably,
> supporting best practices (mimic other open source libraries) will
> ease putting pococapsule into linux repositories. I understand, that
> the only point where header files used in pococapsule - is entrance-
> point (main() function source).
>
I am not sure I understood the issue here. Why you can't store
pococapsule header files in a sub-directory?
>
> > > 5. Cannot generate source code out of setup.xml for compilation and
> > > link with my app if I don't need reconfiguration feature.
>
> > If we do provide such XML to C++ converting, the C++ code would simply
> > be something to create a DOM tree C++ object in memory with calls to
> > create root node, create child nodes, add child nodes, etc.:
>
> > So, we decided to take a much better approach. Namely, instead of
> > generating code that create the DOM tree, we generate the DOM tree
> > itself. This feature is documented in user guide section 2.3.2
> > briefly. Namely, the encoded string generated from pxencode is already
> > a representation of such in memory DOM tree. to use it, you can simply
> > embed this string in your code as:
>
> > const char* descriptor = ".....";
>
> > POCO::AppContext ctxt = POCO::AppContext::create(descriptor,
> > "string");
>
> Using inlined configuration is really an option for me - I am using
> it. But I was rather talking about two other things:
> 1. I like the idea of XML and the whole easy format of bean wiring
> file, but I would like to keep it in a separate file (inline it into C+
> + source will require either implement XML processing in the
> application or will prevent me from using XSD, DSM/XSLT). Inlining it
> dynamically into source code during build can be quite difficult task,
> but also possible.
>
I think you missed my point. The encoded descriptor is no longer a XML
string. It is a streamed C++ structure (DOM tree), just like YACC
generated parsers (C code) are largely data tables. This C++ structure
can be put in any C++ source file (.cpp file) and built into the
runtime executable or as a normal streamed object (in form of text
stream) read from a file, a socket connection, a database record,
etc.. With this encoded descriptor, you no longer need the original
XML descriptor (that is how we test pococapsule in various embedded
OSs where no XML parsers are available) and certainly eliminate any
XML processing in the application.
Also, I don't understand what you mean "dynamically" during "build".
These two concepts are contradicted.
>
> 2. I would like to benefit from C++ static type verification at
> compile-time. Since type-safety of relations between beans in XML is
> not checked,
>
That is no correct. PocoCapsule is strong/static type safe and dynamic
type verified. It is even "over" strong (in the sense that it prohibit
some valid C++ type conversions) than the host language (i.e. c++)
itself. Type safety is _statically_ checked when you build proxies. In
addition, PocoCapsule runtime also performs dynamic type verification
just in case you changed the configuration (especially when signature/
type changes were involved) without rebuilding proxies.
This issue (type safety) is clearly documented in PocoCapsule's user
guide and wiki article.
>
> Further than this, I don't need
> reconfiguration - only pure IoC, just not to hardcode all relations
> and extract initialization outside of my logic, relying on some well
> established generator - relying on pococapsule in my case. And again,
> I would like to build a single executable without setup.xml somewhere
> by.
>
As explained previously and above again and again, the feature of
encoding XML descriptor exactly serves for this requirement. To
emphasize it again, an encoded descriptor is not a XML descriptor. It
no longer needs a XML parser to process and no longer needs the
original setup.xml. It is put C++ code -- a C++ data structure like
the C data table in YACC generated parser C code. You can easily have
an encoded descriptor built into your single executable and certainly
not need to use the original sertup.xml.
Hope I made it clear this time.
Ke
Ke Jin
Again thanks! see inline comments.
Ke
>
> PocoCapsule shouldn't mimic Java, I agree. As I explained earlier,
> subfolder should just separate pococapsule headers from other library
> headers.
>
After all, what prevent you to put PocoCapsule's header files into any
subdirectory you like? My header files are always in a sub-folder.
>
> This trivial evolution leverage clarity and ease of use.
> Besides this, looks like it's a best practice and widely used among
> open-source projects (boost, xercesc, codesynthesis xsd, log4cplus,
> etc).
>
First, I don't see the problem. Second, PocoCapsule is not a
programming framework/library but a container. The differences is: as
programming libraries/frameworks (such as boost, xerces-c, etc.),
exposed API (classes and methods) are heavily used in user code. As a
container, on the other hand, its API should not be used in user's
business logic code and should be less used in application's
initialization code. Typically, PocoCapsule APIs are only called as an
entry/initialization point.
>
> As far as I understand, code generation is still in use - one of the
> best examples I found recently, already mentioned CodeSynthesis XSD.
>
Code generation should only generate logic (as in YACC and
PocoCapsule), instead of generating instances (as in CASE tools). The
deference is whether user specified parameters are generated into the
code.
To stay on the original topic, the short answer (the details have been
described previously and in another reply today) is that PocoCapsule
does provide the required code generation. It generates reusable logic
(proxies -- i.e. logic) and also have user specified parameters/
configurations generated in a C++ data structure.
Regards,
Ke