thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randy Abernethy <randy.aberne...@gmail.com>
Subject Re: Thrift in an embedded setting
Date Mon, 11 Jan 2016 22:52:09 GMT
Most boost usage in Thrift is header based. The C++ lib "API" today uses
boost::shared_ptr liberally and there are lots of other small incursions.
While the elegance of Boost is uncontested, it is another dependency and as
far as the Thrift C++ lib is concerned, it is redundant in the context of
C++ >= 11. There are also boost thread bits which are lib based. Again you
can work around this stuff but it is much easier, and at no cost of
functionality, to just use C++11 these days.



On Mon, Jan 11, 2016 at 2:27 PM, Stuart Reynolds <stu@stureynolds.com>
wrote:

> Just out of interest, what's the nature of Thrift's dependency on Boost?
>
> My recollection (also from embedded systems), is that *much* (but not
> all) of Boost doesn't cause any real library dependencies because so
> much of the Boost code is provided in full as template in header files
> (i.e. it does not necessarily generate linker dependencies on boost
> libraries).
>
> Is this the case for Thrift's use of boost? Does it require some
> linking against a boost library -- and could that dependency be cut?
>
> - Stu
>
>
>
> On Mon, Jan 11, 2016 at 2:06 PM, Randy Abernethy
> <randy.abernethy@gmail.com> wrote:
> > Hey Roger,
> >
> > I agree with the goal. However I think the easiest way to start is with a
> > new base (--gen cpp2). In this way we can get something in place for
> those
> > who need it now and then we can excommunicate the old lib whenever the
> > community is ok with it. The changes contemplated break the API, not
> > something we can just do to the old C++ lib without harming a lot of
> folks.
> >
> > -Randy
> >
> > On Mon, Jan 11, 2016 at 12:04 PM, Roger Meier <roger@bufferoverflow.ch>
> > wrote:
> >
> >> Hi all
> >>
> >> I think we should rework the existing cpp towards modern C++ to awoid a
> >> second lib and generator to maintain.
> >>
> >> The cpp_v2 branch from Konrad is a great place to start, the
> >> modularization and testability is awesome!
> >> As we decided to base on modern C++ such as C++11, I would like to
> >> replace the existing ccp lib and generator instead of adding another
> one.
> >>
> >> I guess this might also enable Thrift on bare metal with C++ compilers.
> >>
> >> best!
> >> -roger
> >>
> >>
> >> Quoting Konrad Grochowski <hcorg@minions.org.pl>:
> >>
> >> Hi Randy,
> >>>
> >>> Do you think we could somehow merge our cpp2 efforts? (
> >>> https://github.com/hcorg/thrift/tree/cpp_v2)
> >>> It's my old branch, had to put it on little hiatus, yet I think some
> >>> parts of it could be useful.
> >>>
> >>> Best regards,
> >>> Konrad
> >>>
> >>> W dniu 11.01.2016 o 20:16, Randy Abernethy pisze:
> >>>
> >>>> Hi Dane and Tomas,
> >>>>
> >>>> Great to hear we have a few people willing to pull the oars. I'll get
> our
> >>>> cpp2 lib sanitized this week and post a jira/patch in a few days.
> Then we
> >>>> can take it from there.
> >>>>
> >>>> Best,
> >>>> Randy
> >>>>
> >>>>
> >>>> On Mon, Jan 11, 2016 at 11:14 AM, Dane Mason <danem.mason@gmail.com>
> >>>> wrote:
> >>>>
> >>>> Hey Randy,
> >>>>>
> >>>>> That sounds perfect for our use case. I would love to contribute.
> Let me
> >>>>> know when you have more details.
> >>>>>
> >>>>> Dane
> >>>>>
> >>>>> On Sun, Jan 10, 2016 at 9:44 AM, Randy Abernethy <
> >>>>> randy.abernethy@gmail.com>
> >>>>> wrote:
> >>>>>
> >>>>> Hey Dane,
> >>>>>>
> >>>>>> My shop has a C++11 (no boost) language implementation for thrift.
> We
> >>>>>>
> >>>>> have
> >>>>>
> >>>>>> only built out the generator (--gen cpp2) TBinaryProtocol,
> >>>>>> TCompactProtocol, framing and basic socket transports. I have
tried
> to
> >>>>>>
> >>>>> get
> >>>>>
> >>>>>> some help cleaning this up for public consumption but so far
no
> takers.
> >>>>>> Also other quarters have threatened to post such a code base
which
> has
> >>>>>> caused us to hold off (don't want multiple versions of this
stuff in
> >>>>>> the
> >>>>>> trunk). If you are willing to contribute I'll try to package
things
> up
> >>>>>>
> >>>>> for
> >>>>>
> >>>>>> a commit this week so that we can get the community to pitch
in and
> >>>>>>
> >>>>> finish
> >>>>>
> >>>>>> off a basic C++11 lib. Should work great for your purposes (which
is
> >>>>>> exactly what we use it for).
> >>>>>>
> >>>>>> Best,
> >>>>>> Randy
> >>>>>>
> >>>>>> On Sat, Jan 9, 2016 at 6:20 PM, Dane Mason <danem.mason@gmail.com>
> >>>>>>
> >>>>> wrote:
> >>>>>
> >>>>>> Sorry I should have been more clear. C++ is fine, but the boost
> >>>>>>>
> >>>>>> dependency
> >>>>>>
> >>>>>>> is problematic.
> >>>>>>>
> >>>>>>> Dane
> >>>>>>>
> >>>>>>> On Saturday, January 9, 2016, Randy Abernethy <
> >>>>>>>
> >>>>>> randy.abernethy@gmail.com
> >>>>>
> >>>>>> wrote:
> >>>>>>>
> >>>>>>> Do you need a C impel or can you use C++11 on the embedded
sys?
> >>>>>>>>
> >>>>>>>> On Saturday, January 9, 2016, Dane Mason <danem.mason@gmail.com
> >>>>>>>> <javascript:;>> wrote:
> >>>>>>>>
> >>>>>>>> Hi, I'm part of a project that makes heavy use of Thrift
and it's
> >>>>>>>>>
> >>>>>>>> RPC
> >>>>>
> >>>>>> functionality across Java, C++, and Python. This project now
needs
> >>>>>>>>>
> >>>>>>>> to
> >>>>>
> >>>>>> incorporate an embedded component with 256kb ram running on
a
> >>>>>>>>>
> >>>>>>>> CortexM3.
> >>>>>>
> >>>>>>> After a bit of research, I've decided that there is no straight
> >>>>>>>>>
> >>>>>>>> forward
> >>>>>>
> >>>>>>> way
> >>>>>>>>
> >>>>>>>>> of using Thrift in this context out of the box.
We are not
> willing
> >>>>>>>>>
> >>>>>>>> to
> >>>>>
> >>>>>> bring
> >>>>>>>>
> >>>>>>>>> GLib in as a dependency, nor are we willing to use
C++ and Boost.
> >>>>>>>>>
> >>>>>>>> What
> >>>>>>
> >>>>>>> we
> >>>>>>>
> >>>>>>>> simply need is a way to reuse the binary protocol and
most
> >>>>>>>>>
> >>>>>>>> importantly,
> >>>>>>
> >>>>>>> the
> >>>>>>>>
> >>>>>>>>> IDL used throughout the rest of the project. We
are using many
> >>>>>>>>>
> >>>>>>>> large
> >>>>>
> >>>>>> structs, so maintaining 4 hand written implementations across
our 4
> >>>>>>>>> languages doesn't make sense.
> >>>>>>>>>
> >>>>>>>>> Some solutions I've considered:
> >>>>>>>>>
> >>>>>>>>> 1. Manually write code serialize and deserialize
the thrift
> binary
> >>>>>>>>> protocol.
> >>>>>>>>> - We are dealing with many large structs, and ensuring
> correctness
> >>>>>>>>>
> >>>>>>>> of
> >>>>>
> >>>>>> this
> >>>>>>>>
> >>>>>>>>> handwritten code is tedious and error prone.
> >>>>>>>>>
> >>>>>>>>> 2. Use a JSON protocol and use existing JSON parsers
on the C
> side.
> >>>>>>>>> - Again error prone, may not be performant enough
for our use
> case.
> >>>>>>>>>
> >>>>>>>>> 3. *Possibly *create something like a "TFlatBufferProtocol"
 (or
> >>>>>>>>>
> >>>>>>>> any
> >>>>>
> >>>>>> other
> >>>>>>>>
> >>>>>>>>> Serialization format with an IDL)
> >>>>>>>>> - I haven't looked into this in depth, it seems
messy and hard to
> >>>>>>>>>
> >>>>>>>> maintain.
> >>>>>>>>
> >>>>>>>>> I'd appreciate any advice you all have to offer
here.
> >>>>>>>>>
> >>>>>>>>> Thanks,
> >>>>>>>>>
> >>>>>>>>> Dane
> >>>>>>>>>
> >>>>>>>>>
> >>>
> >>> ---
> >>> Ta wiadomość została sprawdzona na obecność wirusów przez
> oprogramowanie
> >>> antywirusowe Avast.
> >>> https://www.avast.com/antivirus
> >>>
> >>
> >>
> >>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message