Hi Philip,
you mention a whole list of mostly valid points. But all these issues,
wishes and problems are not the real point here. It's not really about the
obvious things (they could be much better tracked via JIRA), the real crux
lies at a very different place.
You state that you "better write my own serialization library", and indeed
that's what other people already did. Even Thrift was never the first of its
kind, it is built on top of the experiences gained from other projects, such
as protobuf. There are other projects out there who do similar things as
Thrift does, and some even build upon the experiences gained and lessons
learned with Thrift. Think of Avro, think of Cap'n Proto, to name just two.
In that sense, Apache Thrift is only one example of a greater picture, it is
how Open Source software in general lives, grows and evolves. Each project
lives and dies with the people involved and committed to it. Software in
general, and OSS in particular is never perfect, it is never finished and
there is always something to improve, some bug to fix or something to
re-design. Even Donald Knuth had to pay a few cheques.
And yes, in some cases people start forks or re-implement from scratch with
the intention to to do things better than all of their predecessors - and
sometimes that's what they really do. So did Facebook with Thrift. But there
is also that huge heap of unfinished and abandoned projects around ... a
good portion of these suffered from the "mee too" syndrome and the "not
invented here" syndrome, and eventually died from plain and simple lack of
interest. Whoever started either one of these, it for sure was not with the
intention to leave it that way.
Despite that, some of these projects are really successful, people start to
like it and use it big time in productive environments for all kinds of
things. So got Linux traction, and so did a plethora of other OSS tools and
products. But behind all that technology stacked together, at the very
bottom of it, there's still that tiny piece of code where it once started.
It all goes back to that small, proof-of-concept-alike module, which
suddenly came to life, and, after growing and nurturing it, finally did what
the inventors had imagined. It was far from perfect, it was even a bit ugly,
and there was no documentation and no web site, but it worked like hell and
some people saw the potential in it. Some of them joined you and spent their
own time to improve it, to document it, to even write books about it. They
let the community grew by spreading the word about that awesome cool and
powerful tool they just discovered.
Of course, when people come together to work at things, they all have
different backgrounds and priorities, and look for sometimes very different
things. Because of this, things almost never smootly without discussions,
sometimes vehement ones. This is completely normal and it's called "life". A
few of these things that you mentioned are indeed in our focus, and of
course there are some more things on our lists (JIRA and personal ones) that
we plan to do, sooner or later.
The cornerstone of not only Open Source, but basically any project, is
contributions made by people: If there are enough people to just start doing
the things they feel the need for, or see the genius way to make things
better than before, awesome things start to grow.
The only thing needed is very simple, and at the same time very hard. It is
the minute where the magic happens, where someone, somewhere decides to just
start doing something. It does not have to be the big cool new uber-feature.
A lot of the things on your list and in JIRA are indeed quite small things,
such as better documentation, improving the tutorials, fixing some small
bugs, ensuring better quality by improving the cross test, or helping with
releases. These tasks are very important, otherwise they would not have been
on your list. Sure, some of these tasks may even be quite a bit boring, but
nevertheless implementing them will let the product shine. Some contributors
did a great deal of work in that area just in the last weeks.
At the end, it all rises and falls with people that believe enough in the
project to spend a part of their life to it. We need you Thrift users,
Thrift developers who are reading this. We need even you, who already has an
awesome patch in his repo and just hesitates to contribute, because you
think your code will not be good enough. Believe me, it is good enough - and
if there are really flaws in it, we will be glad to help you improving it
and make it great.
And that is what OSS is all about: Building really great things out of
imperfect pieces.
Have fun,
JensG
-----Ursprüngliche Nachricht-----
From: Philip Polkovnikov
Sent: Thursday, October 1, 2015 7:46 PM
To: [email protected]
Subject: Re: How to return more than one value in a Thrift service method?
By the way,
Why does `i32` and `bool` (and several other types) become the same
undistinguishable `binary` in JSON?
Why do you send method names in plain text in a binary protocol?
Why there's no inheritance of struct's in Thrift?
Why Thrift has no obvious way to define methods on client (i.e. server
to client calls)?
Why C# runtime is blocking and single-threaded?
Why sequence id is always zero?
Why does csharp:async imply that I have a fresh version of C#, while
it could've been done with callbacks?
Why feature support table was updated two years ago?
Why there're two JavaScript libraries?
How do I use WebSockets in both of them?
Where's proper API documentation?
How do I determine in a Node.js server that two method calls were from
the same client?
Why did I have to report an issue via maillist that spams my inbox every
day?
Haven't you find more ancient technologies to get feedback?
Why I've got no answer?
What should I do with `version.h` in Visual Studio, finally?
Why does Node.js generator create global variables that fail 'use strict'
check?
Personally I'd better write my own serialization library than patch
thrift once more. In a span of last two months I've rewritten C#, JS
and JSON generators and runtime libraries due to numerous bugs and
missing features. The real question is if Gajanan H wants to fix the
library that is certainly not ready for even basic usage.
2015-10-01 18:18 GMT+03:00 Jens Geyer <[email protected]>:
Generics do not have anything to do with it. golang supports this on the
lgg level and lacks generics big time.
Btw, If you want generics, we accept patches.
________________________________
Von: Philip Polkovnikov
Gesendet: 01.10.2015 14:26
An: [email protected]
Betreff: Re: How to return more than one value in a Thrift service method?
Hello Gajanan,
It's a pity that Thrift doesn't support generics, because it would ideally
be
struct Status<T> {
1: StatusCode Code,
2: T Value
}
service ImportantService {
Status<ImportantData> GetImportantData()
}
The absence of generics lower code reuse, because there's no way to
generically handle StatusCode's if there're methods with several
return value types. I've heard that generics was thought to be not a
very good idea due to a lack of generics (or static typing at all) in
most of supported languages, and one would need to create proxy types.
Protobuf.net uses this workaround for generics. It generates proxies
like List_Int32. Thrift already has some builtin support for lists and
maps, and we could abstract implementation approach from these.
Another solution would be at least to create a pair<T, U> builtin
type. That would allow us to write
struct Status {
1: StatusCode Code
/* extension is possible here */
}
service ImportantService {
pair<ImportantData, Status> GetImportantData()
}
So in case you're concerned with this issue, you could add any of
these features into a generator for the languages you need. We had a
need for attributes on fields and structs in production, so we've
added support into C# and JSON generators, and it was quite easy.
Generator's source code is pretty simple, it's written in a small
subset of C++ without extra dependencies.
2015-10-01 14:24 GMT+03:00 Randy Abernethy <[email protected]>:
Hello Gajanan,
Many consider it a best practice to return a struct in thrift service
methods. This allows you to return multiple values and to evolve the
things
returned over time. Adding new attributes to a thrift struct is a
backwards
compatible operation.
Best,
Randy
On Thu, Oct 1, 2015 at 3:32 AM, Gajanan H <[email protected]> wrote:
Hi,
I have a thrift service method `ImportantData GetImportantData()`
defined
in the IDL. I would like to return a Status code for this method. I
would
like to be doing some thing like `Status
GetImportantData(ImportantData&)`
Is there a way to do that ? Pardon me I am very new to Thrift. BTW I am
using C++ as language.
Regards,
Gajanan
