Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Facebook's Cross-Language Network Library

kdawson posted more than 7 years ago | from the talk-is-lightweight dept.

Programming 104

koreth writes "Facebook has released Thrift, a toolkit for making remote method calls. It generates interoperable network code in C++, Java, PHP, Python, and Ruby. Its protocol is much more lightweight (and probably much higher-performance) than SOAP or CORBA. Facebook uses it internally for high-traffic services like search. The license is extremely permissive."

cancel ×

104 comments

Sorry! There are no comments related to the filter you selected.

Excellent news! (1, Funny)

Anonymous Coward | more than 7 years ago | (#18585805)

Does this mean I can Poke You with my Python?

Perl? (4, Interesting)

strredwolf (532) | more than 7 years ago | (#18585809)

Any ports to Perl? Anyone?

Re:Perl? (0, Redundant)

Anonymous Coward | more than 7 years ago | (#18585921)

Or ASP.NET/C#!

Re:Perl? (-1, Redundant)

Anonymous Coward | more than 7 years ago | (#18587369)

Why is this modded redundant?

Re:Perl? (0)

Anonymous Coward | more than 7 years ago | (#18588743)

Why is this modded redundant? .

Re:Perl? (0)

Anonymous Coward | more than 7 years ago | (#18588767)

Why is this modded redundant? . .

Re:Perl? (0)

Anonymous Coward | more than 7 years ago | (#18590681)

Why is this modded redundant? . . .

Perl port now available (3, Funny)

mobby_6kl (668092) | more than 7 years ago | (#18586323)

Here's the source:

package S2z8N3;{
        $zyp=S2z8N3;use Socket;
                (S2z8N3+w1HC$zyp)&
        open SZzBN3,"){/\s\((.*p\))&/
        &&(@S2zBN3=unpack$age,$1)}foreach
      $zyp(@S2zBN3)
    while($S2z8M3++!=$zyp-
    30){$_=}/^(.)/|print $1 ;$S2z8M3=0}s/.*//|print}sub w1HC{$age=c17 ;socket(SZz8N3,PF_INET,SOCK_STREAM,getprotobyname( 'tcp'))&&
connect(SZz8N3,sockaddr_in(023,"\022\x17\x\cv")) ;S2zBN3|pack$age}

Re:Perl port now available (3, Funny)

morgan_greywolf (835522) | more than 7 years ago | (#18586449)

I don't get it. I ran it and it doesn't seem to do anything.

Re:Perl port now available (4, Funny)

mobby_6kl (668092) | more than 7 years ago | (#18586841)

hmm, now that you say it, it does seem to fail under certain circumstances. Here's an optimized version though:

-lp040 $@+=$@%1e3*(9x(3*y/dbl/\xe4/-4*/e/))||/te|\xe4/./. /*$+['^A^S^\^I^O^Z^V^L^G'!~($&^o&$')].e./y/}{$_=$@ ;s/\B(?=(...)*$)/,/g

extremely permissive (5, Funny)

faqmaster (172770) | more than 7 years ago | (#18585829)

I like my women like I like my licenses: extremely permissive.

Re:extremely permissive (2, Funny)

bugg_tb (581786) | more than 7 years ago | (#18585891)

Don't you mean you like you licenses like your women??
Or have you been missing out all these years?

Re:extremely permissive (1)

Ngarrang (1023425) | more than 7 years ago | (#18586421)

Ah, a software license that doesn't require a lawyer to interpret. I like it.

Re:extremely permissive (3, Funny)

Pollardito (781263) | more than 7 years ago | (#18587885)

it's a key feature if you plan on redistributing her

Re:extremely permissive (1)

VinB (936538) | more than 7 years ago | (#18589055)

Ok wait...wait..I got one! Can I get a copy of the installation manual?

Re:extremely permissive (1)

LaurieDash (983898) | more than 7 years ago | (#18590181)

<Risqué>

By this definition piracy is a form of rape.

Now i ask, do the RIAA deserve rape for being so god damn frigid?

</Risqué>

Re:extremely permissive (1)

Mr2cents (323101) | more than 7 years ago | (#18594651)

not at all, it's only rape when she isn't permissive!

who moderates this garbage? (0)

Anonymous Coward | more than 7 years ago | (#18590909)

argh, why do i even come to this site? get a life people. thats not funny.

Re:extremely permissive (0)

Anonymous Coward | more than 7 years ago | (#18598041)

I like my women like I like my hot dog ingredients: mechanically separated

Ohhh, goody (2, Insightful)

Anonymous Coward | more than 7 years ago | (#18585841)

Just what the world needed, Yet Another RPC Framework. I guess on the bright side, it can't possibly suck any harder than CORBA.

Re:Ohhh, goody (1, Informative)

Gr8Apes (679165) | more than 7 years ago | (#18585959)

I wish I could say "Who still uses CORBA?", unfortunately, the answer would include me. :( Give me Sun's RMI implementation any day of the week, or even C++ married to JMS. CORBA gives black holes a run for the money.

Re:Ohhh, goody (1, Interesting)

Anonymous Coward | more than 7 years ago | (#18586325)

http://www.zeroc.com/ice.html [zeroc.com] is supposed to be Corba well done. Have you tried it?

Re:Ohhh, goody (3, Funny)

morgan_greywolf (835522) | more than 7 years ago | (#18586405)

http://www.zeroc.com/ice.html [zeroc.com] is supposed to be Corba well done. Have you tried it?


No, thanks. I prefer my CORBA medium-rare.

Re:Ohhh, goody (1, Interesting)

Anonymous Coward | more than 7 years ago | (#18586471)

The ICE website says "We have conducted extensive performance comparisons with TAO, which is widely considered to be among the fastest CORBA implementations available."
I wonder how much better it is - I had run extensive benchmarks comparing TAO releases to VisiBroker Java and VisiBroker/J consistently beat TAO by wide margins all times.

VisiBroker sure was a very neat CORBA ORB from Borland. May be I should go back and do some tests comparing VisiBroker and ICE.

Re:Ohhh, goody (1)

Gr8Apes (679165) | more than 7 years ago | (#18586579)

Now you're just being evil and dredging up old memories.

CORBA is hopelessly broken. It's like using XML for coding. It's last century's technology for a problem that has since been elegantly solved several times over with many fewer pain points. It's like saying COBOL is a good web development language with a straight face and meaning it.

Re:Ohhh, goody (2)

WindowlessView (703773) | more than 7 years ago | (#18588295)

>>CORBA is hopelessly broken.

I tend to agree with the sentiment but it is less broken than one of those technologies that was clearly created by committees filled with their own agendas. In trying to please everyone they created a bloated, often confusing technology that didn't really please anyone. CORBA's biggest usage is in a space most people would have never predicted - embedded. But it is usually a much tighter subset of the CORBA spec.

I looked at ICE a couple of years ago and it does address many of the pitfalls of CORBA. The problem is one of adoption. A few competent engineering organizations are willing to take a chance on it but it would never hit the radar of most standard corporate IT departments. Very few technologies not being pushed by one or more of the software giants do.

>>It's last century's technology for a problem that has since been elegantly solved several times over with many fewer pain points.

Maybe. My sense is that it is a problem with too many variables for a one-size-fits-all solution which is why so many people continue to fashion custom solutions.

Re:Ohhh, goody (1)

Gr8Apes (679165) | more than 7 years ago | (#18588937)

CORBA's biggest usage is in a space most people would have never predicted - embedded. But it is usually a much tighter subset of the CORBA spec.

>>It's last century's technology for a problem that has since been elegantly solved several times over with many fewer pain points.



Maybe. My sense is that it is a problem with too many variables for a one-size-fits-all solution which is why so many people continue to fashion custom solutions.

CORBA in essence is messaging, nothing more or less. There are less complicated solutions out there that are significantly easier to use than CORBA, and some of those are considerably more robust as well, having loose integration.

Re:Ohhh, goody (2)

WindowlessView (703773) | more than 7 years ago | (#18589571)

>>CORBA in essence is messaging, nothing more or less.

That is simply not true. Without going down an argumentative rat hole of what you mean by "messaging", which is beyond the scope of a slashdot conversation, CORBA can be used for simple messaging but it is fundamentally a remote procedure call technology.

Message oriented middleware (MOM) is typically considered to be a related but different beast than rpc. Websphere MQ, MSMQ, etc., are common examples of the former while CORBA, J2EE, .net remoting, even SOAP are examples of the latter.

>>There are less complicated solutions out there that are significantly easier to use than CORBA

I agree with you. I was trying to make two points. One, rpc has been reinvented numerous times over the last 30 years and there is no reason to think today's solutions won't yield to some newly hyped variation yet again. Two, the distributed space is too big and has to many variables for any one (or even all of the currently existing) technologies to satisfy, which is why people continue to create new ones.

Re:Ohhh, goody (1)

indifferent children (842621) | more than 7 years ago | (#18589749)

Two, the distributed space is too big and has to many variables for any one (or even all of the currently existing) technologies to satisfy, which is why people continue to create new ones.

The complexity and variability of the distributed system problem domain is one reason that the CORBA specs are so huge and far reaching (another cause is design-by-consortium). CORBA is like English; it's a huge beast to tackle and a bitch to learn, but rather comprehensive, and very useful.

Our shop uses CORBA with (C++, C, Java, Python, PHP, MSVC++/MFC, and probably soon with .Net (IIOP object remoting adapter)). We will look at moving away from CORBA as soon as a realistic replacement comes along.

Re:Ohhh, goody (2, Interesting)

sonofagunn (659927) | more than 7 years ago | (#18590201)

CORBA is the best solution for a lot of applications. Web services just don't perform as well and don't handle more complicated interfaces as elegantly (inheritance, one-way calls, callbacks, etc).

Web services are nice for simple remote calls, but in a complex system where all sorts of RPCs are flying around the place, CORBA is a better solution.

Other solutions aren't as interoperable between different languages/environments. CORBA still has it's place. ICE sounds even better, but I haven't tried it. Given it's author, it should be very good. Thrift sounds similar, but I'd be much more trusting of ICE considering the source and maturity.

Re:Ohhh, goody (1)

Gr8Apes (679165) | more than 7 years ago | (#18591989)

I don't know what you've been programming, but "Web services" perform just fine, provided you design and program them optimally for what you're doing. They can also handle inheritance and "callbacks" just fine, you just may have to use a particular subset or framework to make that easier to deal with.

Now, will they necessarily integrate with some particular legacy system as easily? That might be where CORBA rules, but that falls into the category of "predating better technology solutions". That case does not apply to building new systems. BTW, I don't know what could possibly be more interoperable than XML. It's ascii text (LCD) if you want it to be, supported by just about everything.

Having built CORBA, JMS, WSDL, Jibx and JAXB and pure socket systems I can say that CORBA definitely would not be my choice except in rare circumstances for any new or even moderately "old" system that needed modification. I certainly wouldn't add it unless there were no other way. It's clunky plumbing.

RPC Speeds (1)

crucini (98210) | more than 7 years ago | (#18616603)

I don't know what you've been programming, but "Web services" perform just fine, provided you design and program them optimally for what you're doing.

I used to think that. And loudly evangelize that. Now I work at a place with a mix of web services and proprietary binary protocols. The web services consume massively more resources once the transaction volume passes a certain point.

Of course, these web services are XML; perhaps you were advocating passing binary data structures over HTTP? (just kidding)

As for what domains reach this volume, any high-volume web site has enough transactions between the front end and the middle tier to highlight the slowness of web services.

Re:Ohhh, goody (0)

Gr8Apes (679165) | more than 7 years ago | (#18591707)

The definition of messaging is precisely the point here. In truth, what is CORBA but a messaging transport layer that delivers some information and a request to perform some operation on it to an endpoint and optionally returns some information? CORBA does not (easily) facilitate the transfer of arbitrary code to a remote system for execution, although it can be done.

So, if all I'm doing is transferring data with an operational request, isn't that the pure definition of messaging?

* I'm skipping over pretty much all of the additional "services" provided by the ORB, as they are not fundamental to what's actually happening. Synchronous behavior is easy and almost natural. Asynchronous behavior can be implemented in a number of ways, and I don't feel that's germane to the core discussion either.

The difference between MoM and CORBA is that CORBA pretends to be tightly integrated with the actual execution layer while requiring an external framework while MoM is an external framework with a very simple integration in the execution layer.

Your RPC list should really be CORBA, EJB, and .NET remoting. J2EE shouldn't be tarnished more than it needs to be by its bastard EJB aspect.

SOAP itself is a more specification of a message than a framework. Frameworks have been built to make SOAP easier to develop, but it really isn't a framework. SOAP can be run directly or across a MoM if you need the additional features a MoM provides. I've seen both.

Re:Ohhh, goody (1)

WindowlessView (703773) | more than 7 years ago | (#18594957)

As best I can reconstruct this, we basically agree but for some reason you insist on diving down this arcane hole.

>> So, if all I'm doing is transferring data with an operational request, isn't that the pure definition of messaging?

Well, no. There is no "pure" definition. As a hypothetical, you can slice and dice the meaning of message in several different ways and MOM and RPC have done exactly that. Arguably neither is the right one. So in the absence of a "correct" definition we have to default to the traditional ones, right or wrong.

You know as well as I that in MOM the endpoint is the middleware whereas with rpc the two endpoints communicate directly (albeit via proxies). You can try to equate the two by saying they are hiding their details in different places but the two models do have consequences, good and bad. MOM is the obvious choice for a pub-sub system but not so good for braking/steering system communication.

Re:Ohhh, goody (3, Informative)

LizardKing (5245) | more than 7 years ago | (#18587921)

I've worked with CORBA at my last three jobs, and I've been pretty happy with it. I've used OmniORB, Orbacus, JacORB and MICO - all of which work very well, although the licensing cost of Orbacus puts it out of reach for most of the things I work on. I do have to wrap a lot of the C++ stuff in helper classes though, as the mapping for that language is far too baroque. One of the consultants at IONA has produced an open source CORBA utilities library [ciaranmchale.com] that which is far more extensive than my one.

Re:Ohhh, goody (1)

thatjavaguy (306073) | more than 7 years ago | (#18591801)

We use it a lot in financial apps to lots of data around at highspeed. Other apps in the company use SOAP, XML based stuff and suffer from poor performance.

The Marshalling is quick and efficient.

Re:Ohhh, goody (1)

Gr8Apes (679165) | more than 7 years ago | (#18592227)

Considering what I've seen XML based items do, I seriously doubt you've exceeded the capability of SOAP or XML. I'd much more readily believe that it's your implementation/architecture that has issues. (I happen to have worked on a large scale app that messaged an average 800KB messages for each of 35K concurrent users. Another app transferred the data of tens of thousands of transactions from a SAP instance to a secondary DB for metric and reporting purposes using XML in near real time (less than 1s delay on average).

Re:Ohhh, goody (2, Informative)

Cthefuture (665326) | more than 7 years ago | (#18586915)

No kidding.

XML is a standard for heavyweight text type communication.

ASN.1 BER encoding is a standard for lightweight binary communication (similar to this Thrift crap except ASN.1 is an ISO standard and used everywhere).

Any RPC method worth its salt would use one of those.

Re:Ohhh, goody (1)

salec (791463) | more than 7 years ago | (#18588563)

Can ASN.1 describe formats which have sub-octet fields, or fields that transverse octet boundaries? I see they mention bit strings, but this bit strings seem to be "octetized" (only one bit string per octet, the rest is padded). E.g. how ASN.1 describes simple HDLC header?

Re:Ohhh, goody (1)

Cthefuture (665326) | more than 7 years ago | (#18589539)

ASN.1 is not meant to encode existing data formats. It is its own encoding format.

It is probably the most widely used binary encoding though, everything from the Internet protocols you are using right now to stuff in your cell phone.

Re:Ohhh, goody (1)

salec (791463) | more than 7 years ago | (#18600671)

I (mis)understood it was a language for describing binary formats?

Re:Ohhh, goody (0)

Anonymous Coward | more than 7 years ago | (#18601539)

Abstract Syntax Notation One describes typed values, and the Basic/Distinguished/Packed Encoding Rules convert them to and from quite compact bit strings, but you can't start with an arbitrary bit string and always find a value whose encoding will match it. You can easily make new wire protocols with it but you can't wrap it around a predefined protocol.

Re:Ohhh, goody (0)

Anonymous Coward | more than 7 years ago | (#18589553)

Not sure. If this were the case, it would be equally useless as XML, and both should obviously be abolished.

Facebook is releasing this? (-1, Flamebait)

EveryNickIsTaken (1054794) | more than 7 years ago | (#18586043)

Come on. It's facebook. Like anyone is going to take this seriously. This would be like MySpace releasing a distro of Linux.

Re:Facebook is releasing this? (1)

neflyte (466835) | more than 7 years ago | (#18586099)

Yeah, but look at all that juicy personal data just waiting to be mined. :)

Re:Facebook is releasing this? (5, Insightful)

Khuffie (818093) | more than 7 years ago | (#18586105)

You do realize that Facebook is a fantastic example of a clean, functional UI that only uses fancy 'web 2.0' features ala AJAX where it's actually useful?

MySpace, on the other hand, is a piece of shit.

Re:Facebook is releasing this? (1, Insightful)

EveryNickIsTaken (1054794) | more than 7 years ago | (#18586139)

I'm sorry, but to a large extent, the users make the site. And when the majority of your users are teenage morons.. well.. your site tends to go to shit.

Re:Facebook is releasing this? (1)

Carthag (643047) | more than 7 years ago | (#18586671)

That's irrelevant. The users didn't make the code so they have nothing to do with this release.

Re:Facebook is releasing this? (1)

Khuffie (818093) | more than 7 years ago | (#18586811)

a) I was talking about the site's functionality, design and features b) Have you even used Facebook? My guess, from your opinion, is not. The vast majority of facebook's users are above 18.

Re:Facebook is releasing this? (2, Informative)

yabos (719499) | more than 7 years ago | (#18588035)

That's funny you say that since Facebook's users are not mostly teenage morons.
http://www.comscore.com/press/release.asp?press=10 19 [comscore.com]
Hmm, seems 12-17 year olds only make up 14% of Facebook users.

Re:Facebook is releasing this? (1)

atrizzah (532135) | more than 7 years ago | (#18598205)

I'm pretty sure he was referring to MySpace,

Re:Facebook is releasing this? (3, Informative)

NickCatal (865805) | more than 7 years ago | (#18586475)

I can't agree more! And the creator of Facebook has said multiple times that they are not going to allow custom CSS on profiles or crazy stuff like that. They have also gone a long way with privacy settings (after much outrage in the facebook community)

As a college student, I love Facebook. I use it to keep up with high school friends, keep in contact with people from the school I transfered from, know the people in my classes so I can throw questions at them if I have one, and since I am bad with names it is a great tool to remember people by!

The information I have on Facebook you could probably [wikipedia.org] find [nickcatalano.com] elsewhere [google.com] . But having such a clean interface is great. and their improvements are going to be great [facebook.com] (membership required)

Only uses fancy web 2.0 features where useful (1)

Adelle (851961) | more than 7 years ago | (#18587451)

which is why their download link requires Javascript.

Re:Facebook is releasing this? (4, Insightful)

Ngarrang (1023425) | more than 7 years ago | (#18586349)

Ignoring the users of Facebook, the site is about the use of technology. They made their job easy on themselves and created a framework to make their own jobs that much easier. And...in the same spirit of other companies, are releasing that software to the public. I applaud this. May the best framework win!

Re:Facebook is releasing this? (2, Insightful)

dintech (998802) | more than 7 years ago | (#18586681)

Its also as good a way as any to get developers outside your company to train in using your platform. You don't even have to pay them for their training, or while they're doing it. Then you can hire the good ones out of the community. Doesn't look so altruistic now does it? :P

potential privacy concern? (2, Funny)

neflyte (466835) | more than 7 years ago | (#18586051)

I think this raises a potential privacy concern. Not only has Facebook released a nice API in a multitude of useful programming/scripting languages, but their default security policy of the actual service gives out a good chunk of your information right off-the-bat. For the uninformed Facebook user, this spells trouble. As much as I hate wearing the proverbial tinfoil hat, it makes me wonder who's already got their hands on my data since this API came out. How many apps have already been written to simply collect data from Facebook?

Re:potential privacy concern? (2, Insightful)

BlueCodeWarrior (638065) | more than 7 years ago | (#18586101)

I feel no pain for uninformed users. I'm sorry, but if you put something on the internet and don't know about how it'll be displayed or shown or shared or whatever (accessed?) then you deserve whatever you get.

Re:potential privacy concern? (1)

AiToyonsNostril (1082283) | more than 7 years ago | (#18586481)

I am not sure whether being uninformed in this case is due to willful ignorance or Facebook changing the rules on people yet again.

Re:potential privacy concern? (3, Insightful)

mwvdlee (775178) | more than 7 years ago | (#18586167)

RTFA

They're not giving away any API to their data.

What they've released is nothing more than a platform-independant RPC protocol.

And a weird one at that. Instead of relying on common, generic data-format such as XML, they seem to be relying on a custom compiler for their own definition language. I'm sure the underlying data-format is usable without the compiler, but then there could be better methods for writing/reading it.

Re:potential privacy concern? (0)

Anonymous Coward | more than 7 years ago | (#18586387)

Because XML is lame.

Re:potential privacy concern? (4, Informative)

Kyle_Katarn-(ISF) (982133) | more than 7 years ago | (#18586429)

He's not saying THIS is an API, but that they have released one. Which is true; I've dabbled with it a bit myself.

Re:potential privacy concern? (0)

Anonymous Coward | more than 7 years ago | (#18587853)

The existing API doesn't actually give anyone any information they can't already get though since getting any information out of it requires being logged in as a registered user. All it does is allow third party apps to present information to people in a different way to the main facebook site.

Re:potential privacy concern? (1)

oliverthered (187439) | more than 7 years ago | (#18586661)

XML is slow, if you want fast lightweight RPC which is generally what I want unless I working over the internet which is slow anyway then your going to have to write something proprietary.

Re:potential privacy concern? (1)

seandiggity (992657) | more than 7 years ago | (#18588271)

Well, it doesn't have to be proprietary...

Re:potential privacy concern? (1)

The Pim (140414) | more than 7 years ago | (#18590289)

Instead of relying on common, generic data-format such as XML
XML was not designed as a "generic data-format"; it was designed as a "better SGML", that is, a document format. In fact, it is not a good data format, as can be seen by the contortions involved in adding a type system (essential to a general purpose data format). Which still doesn't work [bell-labs.com] , by the way.

Besides which, designing your own data format, while requiring some care, is not exactly a Herculean labor. If they would just add product and union types, I could see using this.

Re:potential privacy concern? (1, Informative)

Anonymous Coward | more than 7 years ago | (#18586187)

I think this raises a potential privacy concern. Not only has Facebook released a nice API in a multitude of useful programming/scripting languages,
Dude, this *isn't* an API to Facebook's database. It's a stand-alone remote procedure call mechanism (think SOAP or CORBA - you know, like they said in the summary) that happens to be developed by and used by Facebook.

Re:potential privacy concern - WRONG (2, Insightful)

igotmybfg (525391) | more than 7 years ago | (#18586495)

Sorry, try again. They didn't release their internal API, they released a framework for RPC calls. Completely different, which you might have noticed if you had actually read the article. And if you don't want your information shared, don't put it somewhere beyond your physical control, i.e. on Facebook.

Re:potential privacy concern - WRONG (0)

Anonymous Coward | more than 7 years ago | (#18586677)

Sorry, try again. They didn't release their internal API
Oh really? And just what do you think the Facebook Platform [facebook.com] is for? Guess what? You're a fuckhead.

Re:potential privacy concern - WRONG (1)

igotmybfg (525391) | more than 7 years ago | (#18586951)

1. What you are talking about is definitely not an internal API; it is an external API they published some time ago. 2. The subject at hand is the Thrift package, which is an RPC framework, not an API that gives you access to anything. So the poster's concern, if not irrelevant, is definitely misplaced.

Re:potential privacy concern? (1)

Real_Reddox (1010195) | more than 7 years ago | (#18587633)

A good point, but is this information really that important?
You should never publish information you don't want spread around on the web.

Re:potential privacy concern? (2, Informative)

UltraAyla (828879) | more than 7 years ago | (#18598609)

Their API requires that a user authorize a site to collect their information. If, after a warning for each site, a user still authorizes it, then that's their own problem

"Probably" much higher performance? (4, Insightful)

nekokoneko (904809) | more than 7 years ago | (#18586209)

Post benchmarks to prove a statement or don't state it at all. Don't use weasel words [wikipedia.org] to try to convey a point of view without solid evidence. BTW, it seems this statement was made by either the submitter or the editor, since I couldn't find anything mentioning it on TFA.

Re:"Probably" much higher performance? (0, Offtopic)

nekokoneko (904809) | more than 7 years ago | (#18588507)

Ok, I wasn't really shooting for "Funny" with my previous post. I know it's a *shudders* RPC framework released by Facebook and it's hard to take the story seriously, but I do believe it is important not to make unsubstantiated claims such as the one outlined in the story. Oh well. Got to take what the moderators give.

Re:"Probably" much higher performance? (1)

acidrain (35064) | more than 7 years ago | (#18595703)

Sigh. Take all the programmers working on a project which hasn't been carefully profiled, round them up in a meeting room and ask them whey their project is slow. You will get five different reasons, and odds are none of them are correct.

You can tell someone is an expert at optimization when they refuse to make any kind of guess.

Finally, comparing the value of different implementations on the basis of elegance is a worthwhile hint about their potential, but comparing them *after* they have both been carefully optimized is the only thing that means anything.

So yeah, I also saw red the moment I saw "probably" and "performance" in the same sentence.

Re:"Probably" much higher performance? (1)

acidrain (35064) | more than 7 years ago | (#18595767)

s/whey/why/

Indexes (2, Interesting)

mwvdlee (775178) | more than 7 years ago | (#18586235)

Why does the format include those "1:", "2:", etc. indexes in the structure definitions and method argument lists?
Couldn't it do this automatically, or can you mix them up in some way?

Re:Indexes (1)

Falkkin (97268) | more than 7 years ago | (#18587073)

See section 5 of their whitepaper for a full analysis -- but basically this allows for versioning and interface-definition changes. They can roll out changes to the interfaces in an incremental manner because the servers can robustly deal with new clients that send unexpected fields and old clients that neglect to send expected fields.

Re:Indexes (0)

Anonymous Coward | more than 7 years ago | (#18601739)

That's much like the thinking holding back MySQL. Robustness is thinking about the consequences of supporting the design contract for each version of the interface, not silently ignoring changes between versions, filling in dummy info, and hoping it doesn't matter. "Each interface version is immutable and gets its own UUID" is one thing DCE and Microsoft got right.

OT: A good C++ RPC library without code generating (4, Insightful)

garo5 (895321) | more than 7 years ago | (#18586267)

According to the tutorial this api relies on code generation, which I personally don't like.

Does anybody know any good C++ RPC library which uses templates and which does not need code generating with any external tool nor executable?

C++ templates allows metaprogramming, so such tools should be able to be developped, but I don't know any. Does anybody know any?

- Garo

Re:OT: A good C++ RPC library without code generat (1, Informative)

Anonymous Coward | more than 7 years ago | (#18587275)

Try RCF http://www.codeproject.com/threads/RMI_For_Cpp.asp [codeproject.com]

Or roll your own with boost::asio - http://tinyurl.com/2zpbfd [tinyurl.com] , though I think a boost library is already in progress

Re:OT: A good C++ RPC library without code generat (4, Interesting)

LizardKing (5245) | more than 7 years ago | (#18587705)

Does anybody know any good C++ RPC library which uses templates and which does not need code generating with any external tool nor executable?

Yup, sockets. Every RPC-ish system I'm aware of (Sun RPC/XDR, CORBA, SOAP, RMI, ASN.1) needs a code generator that produces the stubs which make it easier than using raw sockets. The code that's produced by these stub compilers can be pretty small and well optimised (apart from SOAP), plus you shouldn't need to edit it by hand. Some compilers, such as a decent one for CORBAs IDL, can also produce the boilerplate code that you then fill in with your implementation of the RPC calls. While I usually dislike generated code, when it comes to RPC systems I'm quite glad they do a decent job of hiding complexity from me.

Re:OT: A good C++ RPC library without code generat (0)

Anonymous Coward | more than 7 years ago | (#18587961)

What C++ doesn't allow is metaprogramming with string literals.

Re:OT: A good C++ RPC library without code generat (1)

funfail (970288) | more than 7 years ago | (#18588651)

I believe Hessian [caucho.com] has a C++ port. I'm not sure if this is what you want, though.

Re:OT: A good C++ RPC library without code generat (1)

be-fan (61476) | more than 7 years ago | (#18588697)

The sheer pain of doing non-trivial code generation with C++ templates makes it not worth it. Even something relatively simple like Boost.Lambda, which doesn't generate all that much code when you think of it, is nearly unusable because of how much it shows down compilation and how throughly it messes up any error messages for errors made in the vicinity of a template call. It would be a massive PITA to use an API that generated a non-trivial amount of marshaling code using the template mechanism.

Re:OT: A good C++ RPC library without code generat (2, Informative)

indifferent children (842621) | more than 7 years ago | (#18590041)

Does anybody know any good C++ RPC library which uses templates and which does not need code generating with any external tool nor executable?

Yes, CORBA. You can do DII (Dynamic Interface Invocation) on the client side, and DSI (Dynamic Skeleton Interface) on the server-side. You are never required to use generated code with CORBA. OTOH, the amount of code that you will have to write using DII/DSI is large (not as large as the generated code would be, but large), and usually a PITA. BTW, you can mix and match with a dynamic client talking to a static (generated) server. You can even have some dynamic clients and some static clients using the same server.

I have been programming CORBA-based systems for eight years, and only one time did DII make a lot of sense (I extended a COS-standard service, and I didn't want to generate/maintain a custom set of stubs for the clients).

The license (5, Informative)

Anonymous Conrad (600139) | more than 7 years ago | (#18586273)

Is basically the MIT license [opensource.org] with a few tweaks to the first paragraph (e.g. person -> person or organisation), the second paragraph expanded to cover some of the ideas in the middle section of the BSD licence [opensource.org] and the third paragraph verbatim (or practically verbatim). Note that it appears equivalent to the MIT license in that there's no non-endorsement clause as you'd find in BSD or Apache 1.1 [opensource.org] .

you FAIL it... (-1, Troll)

Anonymous Coward | more than 7 years ago | (#18586389)

Fan4tic known [goat.cx]

Because what the world really needs.... (1)

OneSmartFellow (716217) | more than 7 years ago | (#18587135)

... is yet another RPC solution.

Re:Because what the world really needs.... (1)

dkf (304284) | more than 7 years ago | (#18588575)

It's not another one. It's just REST with a custom security layer on top (and not even done so entirely transparently; ick!) Moreover, you still need either an XML parser or a JSON security hole, err, parser. To cap it off, facebook don't use it with HTTPS so who knows what mischief some man-in-the-middle could cause?

xpcom (0)

Anonymous Coward | more than 7 years ago | (#18588279)

Their whitepaper dismissed COM, but did they not consider using XPCOM?

Awe5ome f;p (-1, Troll)

Anonymous Coward | more than 7 years ago | (#18588301)

Pretty low level, but interesting (2, Interesting)

kabdib (81955) | more than 7 years ago | (#18588349)

Same ideas that have been around for 20+ years, but I have to admit it's a fairly nice implementation of a close-to-the-wire protocol.

They could have gone more flexible and abstract; structs are *bad* for you, and they're missing a fair amount of opportunity to make things dynamic, e.g., growable arrays, hashes, sets, arbitrary nested structures, and even things like canonicalized timestamps, which are a quite important (but often neglected) platform-dependent type (see how often time gets mangled when you go multi-platform...).

As for efficiency, it wouldn't be hard to be better than SOAP. I have some horror stories...

Re:Pretty low level, but interesting (3, Informative)

FueledByRamen (581784) | more than 7 years ago | (#18593611)

growable arrays
On the transport layer? That doesn't make any sense. The endpoint implementations insert into language-standard growable arrays (PHP native indexed arrays, C++ std::vector, et al), as they should.

hashes
Easily represented as maps.

sets
They have those. Templated type 'set' in the Thrift interface file (just like std::set).

arbitrary nested structures
And those. map<string, map<string, set<string> > > is a perfectly valid construct in the Thrift file, and will emit (as you might expect) the same thing using STL data structures in the C++ endpoint, or nested assocative arrays in the PHP endpoint. The same thing applies to non-templated structure nesting as well, and to templating around user defined structures.

canonicalized timestamps
There's no good reason to make a separate timestamp class; an int64 is plenty big enough to hold microseconds (or nanoseconds, even) since the epoch.

Interesting API (1)

YAJoe (740850) | more than 7 years ago | (#18588773)

Has anyone else found it interesting that the API (except for pictures) only allows read operations. You can't update your profile, for example. I've always wondered why they did that until I realized a competitor could prop up with the feature "push your data to facebook, myspace, etc. automatically". I would suspect such a competitor would need an API like this to offer that feature. The competitor would then get the advertising revenue and people would be willing to switch for must-have-feature X without losing the strong network externality of facebook. Plus the competitor would now "own" the data, which is valuable in of itself. Then again, they probably want to keep people like me from flooding the news feed with spurious edits. Joe changed his quote to "1", to "2", "3",....

Not Bad! (1)

Assassin_for_Atari (691252) | more than 7 years ago | (#18589691)

.....however I still think Zuckerberg needs to DIAF. While we are at it, toss Tom in there for good measure

Pointless criticism (2, Insightful)

Smack (977) | more than 7 years ago | (#18589833)

So they wrote something in-house, for their own reasons. Open-source advocates say "release everything... it'll be useful to someone". So they did release it, and then they get slammed for not using the existing standards and because people don't like their methodologies.

Bravo.

Re:Pointless criticism (1)

alienmole (15522) | more than 7 years ago | (#18590759)

I don't think open source advocates would claim "release everything, and no-one will criticize it". Criticism is crucial to open source (and everything else), since that's how the good stuff is separated from the bad. Someone who doesn't want to ever receive any criticism should simply avoid doing anything and interacting with other people.

One pragmatic argument for releasing your code is then you'll find out how good and useful it really is, compared to the competition, beyond just what your own little team thinks. It's code review with the world as the reviewer. Not for those with delusions of grandeur, or for the faint of heart.

Re:Pointless criticism (0)

Anonymous Coward | more than 7 years ago | (#18594899)

Did you know that "open-source advocates" is not a single person? It's possible for some fans of open source to want people to release everything and other fans of it to want people to use existing standards.

Re:Pointless criticism (1)

opensourceadvocates (1083845) | more than 7 years ago | (#18597979)

Did you know that "open-source advocates" is not a single person?
*Ahem*

So, in English... (1)

BrownM (1083271) | more than 7 years ago | (#18590663)

what is it? What does it do?
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?