The official site as well as some other sources describe one of the benefits of Google Protocol Buffers as being highly inter-operable. I know the technology supports different language bindings out of the box, and many more as third party implementations, but what does that mean exactly?
Is my understanding correct in thinking that as long as I have a common schema file, I can run the protoc compiler and generate code for multiple languages, and then write a program in one language using the generated code, serialize some data to a file, and then parse it in another language in another program?
For example, could my client-side application running in Java serialize a Google Protocol Buffer and send it over the wire to a server implemented in C++ which can then parse it and use it readily as long as both sides were generated from the same schema file?
If that is correct, what allows that to happen - is it that their serialization/parsing logic adhere to a common/consistent wire format detailed here?
Yes, you can, and yes, it is because the wire format is fixed (i.e. the same for any language binding).
Related
I have these relatively big log files which are generated from a machine via a serial connection.
This log isn`t structured and I need to check various different things. I wonder if there is some kind of existing language or tool which is specialized in this kind of thing?
languages I currently know:
c and c++
python
some java
various scripting language
I hope some of you have a good recomendationt!
Going with what you already know, Just use regular expressions in python.
ok there is no real way to connect to soap within ios5... sadly enough.
I cant really believe that things that take 3 lines of code in php,
$client = new SoapClient("scramble.wsdl");
print($mirror = $client->sendAndGetString("hello_world"));
need 366 lines of code in objective c? And that on a device that has one of the biggest number of ria's and web apps.
Kind of disappointing -
Are there any new libraries I am not aware of?
If I talk to our web developer team they maybe switch to another service type that is more supported by IOS.
What would be a alternative then?
Thanks
The difference between dynamically typed languages such as PHP and statically typed languages such as Objective-C regarding RPC protocols is that while dynamic languages typically allows you to wrap "any" service in run-time by reflecting out their metadata (e.g. WSDL), statically typed languages normally requires a code generation step before the compilation phase.
Two popular code generators seem to be wsdl2objc and sudz-c. See also this question.
Regarding alternatives, I have good experience using both JSON and XML-RPC, as well as the more schema-oriented Thrift and Protocol Buffers (ObjC).
I've written several tutorials about using SOAP services in iOS with Wsdl2Objc: http://brismith66.blogspot.com/search/label/iPhone%20Development
For me the easiest way is to use good tool to generate all required classes. Personally I use this site:
http://easywsdl.com/
It supports quite complex web services and is very easy to use.
Just curious - are protocol buffers usable with F#? Any caveats etc.?
I'm just trying to answer this question myself.
Marc Gravell's protobuf-net project worked out-of-the-box with F# because it uses standard .NET idioms. You can use attributes to get serializing without having to write .proto files or do any two-stage compilation, or you can generate the necessary code from standard .proto files. Performance is good for .NET but a lot slower than alternatives like OCaml's built-in Marshal module. However, this library forces you to make every field in every message type mutable. This is really counter-productive because messages should be immutable. Also, the documentation leaves a lot to be desired but, then, this is free software.
I haven't managed to get Jon Skeet's protobuf-csharp-port library to work at all yet.
Ideally, you'd be able to serialize all of the built-in F# types (tuples, records, unions, lists, sets, maps, ...) to this wire format out-of-the-box but none of the existing open source solutions are capable of this. I'm also concerned by the complexity of these solutions: Jon Skeet's is 88,000 lines of C# code and comments (!).
As an aside, I am disappointed to see that Google protocol buffers do not specify standard formats for DateTime or decimal numbers.
I haven't looked at Proto# yet and cannot even find a download for Froto. There is also ProtoParser but it just parses .proto files and cannot actually serialize anything.
There isn't an F# specific one listed here, but there is an OCaml one, or there is a .NET "general" one (protobuf-net).
In all honesty, I simply haven't gotten around to trying protobuf-net with F# objects, in part because I simply don't know enough F#, but if you can create POCOs they should work. They would need to have some kind of mutability (perhaps even just private mutability) to work with protobuf-net, though.
If you are happy to generate a C# DTO and just consume that from F#, then protobuf-net or Jon's port should work just fine.
I'd expect both my own port and Marc Gravell's to work just fine with F#, to the same extent that any other .NET library does. In other words, neither port is written in a way which is likely to produce idiomatic F# code, but they should work.
My port will generate C# code, so you'll need to build that as a separate project for your serialization model - but that should interoperate with F# without any problems. The generated types are immutable (with mutable builders) so that should help in an F# context.
Of course, you could always take the core parts of either project and come up with an idiomatic F# solution too - whether you port the whole project to F# or use the existing libraries with an F# code generator and helper functions, or something like that.
This is closely related to another question I asked: Is there functionality that is NOT exposed in the Open XML SDK v2?
I am currently working with Open XML files manually. I recently had a look at the SDK and was surprised to find that it looked pretty low level, quite similar in fact to the helper classes I have created myself. My question is what exactly does the SDK v2 take care of that you would have to do manually when coding by hand with an XML library?
For example, would it automatically patch the _rels files when deleting a PowerPoint slide?
In addition to Otaku's links, this shows an example (near the bottom) of navigating an OpenXML document using the IO.Packaging namespace versus the SDK.
Just like Microsoft states on the download page for the SDK:
The Open XML SDK 2.0 for Microsoft
Office is built on top of the
System.IO.Packaging API and provides
strongly typed part classes to
manipulate Open XML documents. The SDK
also uses the .NET Framework
Language-Integrated Query (LINQ)
technology to provide strongly typed
object access to the XML content
inside the parts of Open XML
documents.
The Open XML SDK 2.0 simplifies the
task of manipulating Open XML packages
and the underlying Open XML schema
elements within a package. The Open
XML Application Programming Interface
(API) encapsulates many common tasks
that developers perform on Open XML
packages, so you can perform complex
operations with just a few lines of
code.
I've worked pretty much only with the SDK, but for example, it's nice to be able to grab a table out of a Word document by just using:
Table table = wordprocessingDocument.MainDocumentPart.Document.Body.Elements<Table>().First();
(I mean, assuming it's the first table)
I'd say the SDK does exactly what it seeks to do by providing a sort of intuitive object-based way to work with documents.
As far as automatically patching the relationships -- no, it doesn't do that. And looking back at how you actually state the question, I guess I might even say that (and I'm fairly new to Open XML so this isn't gospel by means) the SDK2.0 doesn't necessarily offer any extra functionality, so much as it offers a more convenient way to achieve the same functionality. For example, you still need to know about those relationships when you delete an element, but it's a lot easier to deal with them.
Also, there's been some efforts on top of the SDK to add even more abstraction -- see, for example, ExtremeML (Excel library only. I've never used it but I think it does get into things like patching relationships).
So I'm sorry if I've rambled a bit too much here. But I guess my short answer is: there's probably not extra functionality, but there's a nice level of abstraction that makes achieving certain functionality a lot easier to handle -- and if you've been doing it by hand up until now, you'll certainly have the understanding of the OPC to understand what exactly is being abstracted.
As a starting point, read this from the Brian Jones & Zeyad Rajabi blog.
I don't know of a side-by-side comparison, but the following articles/videos do discuss the two:
Using the Open XML SDK 2.0 Classes
Versus Using .NET XML Services is
a good place to start comparing the
two.
Open XML and the Open XML SDK is
a deep dive video which discusses both.
Finally, this is a What's New for 2.0 - it can be assumed that neither 1.0 or hand-coding have these benefits.
I wonder whether there's a way to program a resource DLL for Windows Clusters in Delphi. I want to write a program that observes cluster state changes.
Judging from the MSDN API reference, all relevant functions are located in the ClusAPI.h and ResAPI.h headers, but unfortunately it seems as if they haven't been ported yet and HeaderConv seems to fail on them.
Does anyone has experience in doing such a thing?
It's a very C-oriented API, with mandatory Dll entry points, tables of callback function pointers, and binary data blocks. I've been able to wrap a C#/.NET library with a C++/CLI interop layer, but it's definitely non-trivial.
This would require a manual C header translation to Pascal code. If the API deals in pointers, you wouldn't have to translate any structures... this would make it comparatively simple to perform the translation as you'd only need to translate the function declarations themselves. If it passes structures (as opposed to pointers there-to) you would have to translate all of those structures as Delphi Records (or Packed Records as appropriate). Structure translations are far more time-consuming.
Sorry I can't offer an "instant solution", but at the info I've provided should help (if you didn't already know it).