Maybe something like Google's Protocol Buffers? They use it internally, efficient binary protocol, java bindings from google and a third-party c# library. http://code.google.com/apis/protocolbuffers/docs/encoding.html
On Fri, Feb 5, 2010 at 12:12 PM, Rick Bullotta < [email protected]> wrote: > There are big performance and scalability challenges with most REST-ful > interfaces when compared to local invocations, largely due to things like > connection establishment, two-ended serialization, limits on # of > connections/sockets, and so on. Don't get me wrong: It works well, I'm a > big fan of the approach and have implemented REST-ful interfaces to every > product I've ever done. But there is typically a 1-2X order of magnitude > performance gap, depending on how you implement it. Interestingly, by > eliminating/reducing serialization overhead (avoid most frameworks' > built-in > serialization, which usually sucks), you can eliminate a big piece of that > performance hit. > > What I've found works well is supporting multiple "wire formats" - XML/JSON > for the "loosely coupled" consumers, and binary and/or streaming formats > for > "close friends" or non-browser clients. > > -----Original Message----- > From: [email protected] [mailto:[email protected]] > On > Behalf Of Taylor Cowan > Sent: Friday, February 05, 2010 11:51 AM > To: Neo user discussions > Subject: Re: [Neo] Heresy > > Rick is correct in highlighting this. > > A lot of people (java developers) will be looking for something to pivot > on. > Perhaps ready to role client libs for the REST interface under work. > Nolios > did some kind of integration with .net and their restlets engine. > > Taylor > > > ----- Original Message ---- > From: Rick Bullotta <[email protected]> > To: Neo user discussions <[email protected]> > Sent: Fri, February 5, 2010 10:41:23 AM > Subject: Re: [Neo] Heresy > > Hi, Peter. > > Having ported big applications and libraries to and from .NET and Java, in > general, a "rewrite" is the best approach. The code looks surprisingly > similar, but exploiting platform and framework-specific capabilities for > file I/O, threading, memory management, transactioning, and so on are > essential. > > The so-called interpreters/translators, at the bytecode or source level, > generally don't work well except in a few edge cases. > > Rick > > -----Original Message----- > From: [email protected] [mailto:[email protected]] > On > Behalf Of Peter Neubauer > Sent: Friday, February 05, 2010 11:35 AM > To: Neo user discussions > Subject: Re: [Neo] Heresy > > Hi there, > I know of some minor attempts to do that, and some major that might be > underway, but never heard back from the persons involved. Not sure on > the status of such thinking. We would love to do such a bridge, but it > seems it is still after all these years not trivial to either run the > Java code directly in .NET with something like IKVM, or to properly > bridge things. Very strange since the platforms are very close to each > other in thinking. > > Cheers, > > /peter neubauer > > COO and Sales, Neo Technology > > GTalk: neubauer.peter > Skype peter.neubauer > Phone +46 704 106975 > LinkedIn http://www.linkedin.com/in/neubauer > Twitter http://twitter.com/peterneubauer > > http://www.neo4j.org - Your high performance graph > database. > http://gremlin.tinkerpop.com - The terminal to the Giant Global Graph. > > > > On Fri, Feb 5, 2010 at 5:23 PM, Rick Bullotta > <[email protected]> wrote: > > Yes, yes, I know Microsoft is pure evil and all (though not as evil as > Apple > > or Google these days), but has anyone considered the feasibility of a > > C#/.NET port of Neo? > > > > > > > > Just a curiosity more than anything else. > > > > _______________________________________________ > > Neo mailing list > > [email protected] > > https://lists.neo4j.org/mailman/listinfo/user > > > _______________________________________________ > Neo mailing list > [email protected] > https://lists.neo4j.org/mailman/listinfo/user > > _______________________________________________ > Neo mailing list > [email protected] > https://lists.neo4j.org/mailman/listinfo/user > > > > > _______________________________________________ > Neo mailing list > [email protected] > https://lists.neo4j.org/mailman/listinfo/user > > _______________________________________________ > Neo mailing list > [email protected] > https://lists.neo4j.org/mailman/listinfo/user > _______________________________________________ Neo mailing list [email protected] https://lists.neo4j.org/mailman/listinfo/user
