> 1) The RPC method could receive
> parameters that are json values
> without copy operation cost. For example:
>
> using namespace cppcms;
>
> void my_json_rpc_method( json::object& o,
> json::array& a, std::string& s);
>
You already can bind any callback of type
typedef booster::function<void(json::array const &)> method_type
It allows you to do 0 copy
> 2) And could response json values without copy operation cost.
> That is cppcms::rpc::json_rpc_server could have the
> following methods:
> void return_result( json::object const & o);
> void return_result( json::array const & a);
> void return_result( std::string const & s);
Why not to create json::value that can be json object in first
place?
> 3) Add the possibility to a json::value
> object to point to an exists json::object,
> json::array or json::string. That is
> required for access the facilities
> that have json::value methods without copy operation.
This would require entirely different and not always
clear semantics.
Currently json::* is value type and I'm not sure that
adding non-value semantics would not make it dangerous.
What happens on copy? Shallow or deep?
On the other hand you can do
json::value my_huge_value;
foo["bar"]["bee"].swap(my_huge_value)
Which provides move semantics and reduce the
need of copy.
> For example, currently, if I want to print a json::array I have to do:
> json::array a;
>
> //...
>
> json::value v = a;
>
> std::cout << v;
Why not:
json::value v = json::array();
v.array().swap(a);
std::cout << v;
> This leads to an unnecessarily copy operation. I suggest adding the
> following methods to json::value class
You can use move semantics with swap member functions.
The semantics change you suggest is too radical.
Same can be done for example with reimplementing
json using tree of shared_ptr's but it would lead to different
semantics.
I don't think I want to touch this.
> Cppdb
First CppDB is not part of libcppcms and developed independently.
so this is not really question about CppDB.
> 4 ) Boost fusion integration.
> Posibility to fetch fusion sequences
> from cppdb::result, for example:
Ok...
This would I say big... huge, giant NO.
Several reasons.
1. Boost has huge drawback not being backward compatible
neither in ABI nor in API between its releases and tend to
break API every 3-4 month.
You probably had already noticed that Boost is never used
in CppCMS and CppDB API. And there is good reason for this.
2. Things like Fusion, Proto and some other "friends" lead to
enormous compilation times and do not provide too much
help.
> template <typename T>
> void fetch_sequence(cppdb::result& r, T& t )
> boost::fusion::for_each(t, fetch_functor(r) );
> }http://
Why not create a simple project of "Boost CppDB binders"
of such type.
Also one of the advantages I see in CppDB is clear
and simple API with some syntactic sugar.
I want things like Fusion, Proto and other Boost crap
to stay away from my libraries.
They makes code to compile for hours, lead to unreadable
error messages.
Don't get me wrong, Boost is great project but some parts
should be taken with great care.
I don't want to scare away my users.
> 5) Add the posibility to the library client to extend
> fetch and bind to custom types. For example add the
> following interface for fetch custom types:
Custom value? Object? How do you bind its members? by name?
by position? What about partial updates?
Biding by name slow (yep) binding by position is not
really possible for non-trivial queries..
See CppDB is not ORM and is not meant to be such thing.
> Library user code for boost::optional fetch:
Actually probably Boost.Optional is the only
thing that seems to be useful there as replacement
of NULL values.
But currently I prefer CppDB not to depend on Boost
at all.
If I decide to submit it to Boost the sate may change but
not at this point (too much headache)
Best,
Artyom
|
