I'd like to use the AWS C++ SDK in a C library. However, the library build only supports C++.
Does anyone know if there's a C wrapper for the SDK ? There are far too many methods to easily change the code.
Or should I just call the mangled methods (not portable) ?
You can write a wrapping C++ code, which wraps the library, and export the main methods in 'C' mangling. using 'extern "C"' at the functions decelerations.
I've writtend such a wrapper for having s3 client, having methods to create/destroy s3 client/transfer client, and upload/download a file (code is company proprietary so I can't share it).
I think this is better than implementing the http api using curl, as writing your own client is complex, and you may want other features (and bug fixes) which you get out of the box if you use the sdk (such as using kms,recovery handling etc.)
Related
In my hunt for various GUI frameworks, I remembered GTK being a fairly mature library for making user interfaces for desktop applications.
And it got me wondering, is it possible to use the Glade interface designer with Scala? Is there perhaps a Scala-optimised framework or library to make the process more painless?
It appears that there exists a GTK+ binding for Java, and from an unofficial source it seems like you can use this in Scala.
This binding contains class Builder with method addFromFile(), so you should be able to create a UI file in Glade, save it, then load it in your Scala project, and use the method getObject() to access the objects defined in Glade.
For more details you can refer to this question and its answers, which deal with Java, but should be very similar to Scala.
As Scala is interoperable with Java, you can use it's bindings. I highly recommend you to first see a scala REPL micro tutorial for Ubuntu then read and understand what is GtkBuilder and how to create Gtk+ interfaces using Glade. Then a proposed process could be:
Create your apps UIs using Glade
Call GtkBuilder in your Scala code to interact with UI parts (send receive data)
Create Scala script file for each UI
Create a separate backend app with REST interface to present app input/ouput as UI state changes
Connect the two apps
By doing so, you'll get a set of bash scripts (written in Scala) each draw a native UI when executed. Whenever the backend is running, it's possible for UI to be used as I/O of backend app.
From the below link I understood that GWT supporting only a subset of classes or methods in the following package in client side.
java.lang
java.lang.annotation
java.util
java.io
java.sql
https://developers.google.com/web-toolkit/doc/1.6/RefJreEmulation#Package_java_lang
Why is it so?
I think it make more problem in development because I am using only GWT client and using REST Web service instead of server.
Is there any new release of jar like gwtx (new release for supporting persistence,annotation etc) for using all classes and methods in the above packages.
and my main doubt is why they are not supporting all?
To support translating Java to JavaScript, every standard class has to be emulated, i.e. recreated in such a way that the GWT compiler knows how to translate it to JavaScript. An ArrayList for instance is based around a JavaScript Array, String methods have to be emulated on top of a JavaScript String, etc.
And there are things that are simply impossible to emulate (files, sockets). A few other things are not emulated on-purpose, because the emulated version, while technically possible, would be much less performant than a more direct mapping of the browser APIs, and GWT strives for performance (third-party libraries, such as GWTx, can provide such emulations if needed) more than compatibility (the choice of Java as the language was primarily to leverage tooling, not provide a compatibility layer to allow reuse of existing libraries).
Finally, reflection is not supported as it would make it impossible for the compiler to prune dead code and do all its optimizations: how would it know that a particular class, field or method is not actually used by reflection rather than direct calls?
Is there a general Cocoa or Cocoa Touch library for interacting with any web service API, or one which can be used as a basis for creating my own library for a web service? For example, I could add some details about how to interact with the Vimeo API (how to verify user details, what URLs to call). I'm not sure how this would work in reality.
If not, can anyone suggest an web service library which I could alter to change the API calls? It would need to be fairly simple (a small API) and easy to adapt. An example is this Cocoa library for Twitter (although it would probably be too complicated to adapt). Would it be easier just to code it up from scratch?
I don't think there is a library that will automagically work with any web API. In fact I don't even think it's possible to write such a library, since you can define your web API any way you want to. That library would have to be pretty smart in order to figure out how to use an arbitrary API.
I think the closest you'll get is something like ASIHTTPRequest, which is a great library for interacting with web services. If you add a JSON and/or XML parser you'll have everything you need to interact with almost any web API.
Found another library for interacting with RESTful web services. It's called RestKit. From their description:
RestKit is a Cocoa framework for interacting with RESTful web services in Objective C on iOS and Mac OS X. It provides a set of primitives for interacting with web services wrapping GET, POST, PUT and DELETE HTTP verbs behind a clean, simple interface. RestKit also provides a system for modeling remote resources by mapping them from JSON (or XML) payloads back into local domain objects. Object mapping functions with normal NSObject derived classes with properties. There is also an object mapping implementation included that provides a Core Data backed store for persisting objects loaded from the web.
I am developing an application in GWT which needs to call a native C++ code in Directshow to do some multimedia processing.I am guessing that I cant use JNI because GWT converts code to javascript.I did have a look at similar posts on the forum(and on GWT site about JSNI) but cant find a example that specifically talks about calling C++ code from GWT(its mostly about calling Java code from Javascript).Can anyone throw some light on this or direct me to a tutorial?
Where exactly is this code supposed run? Surely not on the client-side. Client-side native code is nowhere near mass adoption.
GWT can either interface with JSNI in order to write native JS code inside your GWT Java code, or to interface with Java back-ends, whilst the framework handles the RPC. Even without GWT you have no way to run native code from within the browser (at least in the near future).
Bottom line - if you can't do it in plain vanilla Javascript on the client side, you can't do it in GWT.
What you can do is use this native code in the back-end, and call it via classic JNI from your Java back-end classes (and then what difference does it make if it's part of a GWT project or not?), but it sounds like this is not the case.
First of all, have a clear separation of Client (HTML / Javascript running in the browser) and server components (java service servlets).
If I understood your problem statement right, You need the UI to collect parameters for your transcoders and your transcoders need to run on a Windows box.
You can look up any simple GWT application to figure out how to serve a GWT application in any container (perhaps jetty for the time being) and process basic HTML form inputs. Once you have all the parameters on the server, you need to figure out how to delegate these parameters posted from the browser (your GWT application) from the service servlet (running within a web server) to your DirectShow application. This point onwards its a java application talking to a native process problem.
You can use various ways to communicate parameters to your native directshow application. Simplest solution is to initiate the application with the exec method passing command parameters inline. Otherwise you can communicate to a running native application via TCP sockets or integrate the native app using JNI. It all depends on your architectural design, which approach you wish to take.
For web application development, I've been steeped in dynamic languages such as Ruby, PHP, and Python. Using popular frameworks for these languages, all my knowledge about HTML, CSS, and JavaScript transfers fairly straightforwardly: templates are basically HTML with embedded code that the server executes to generate the dynamic sections of the page.
Lately, I've been thinking about using GWT for building the UI of my next project. At this point, I'm just trying to wrap my head around how development with GWT works, as seems to follow an entirely different paradigm. In addition, it seems there's an unstated assumption that the server-side part of the app is written in Java. Would it be impractical to use something other than Java for the server side?
Related question:
GWT + GAE python: frameworks for COMET & RPC
While not actually impractical I would say that you get the most value from GWT by having the same code on client and server, since it allows for easy code reuse (fx. if your data objects are serializable then you could just send them directly to the client). So I guess my answer would be; yes you can do it and it's going to be more work than just having Java on the server side.
I don't think there's any requirement that you use Java on the server. At the end of the day, GWT compiles Java to JavaScript. You can do all the comms via the RequestBuilder object, you don't have to use the RPC services.
I guess the question is: if you don't like/know/prefer Java on the server side, why would you use it on the client when it's effectively an abstraction over JavaScript anyway?
There is no requirement to use Java on the server side. GWT supports JSON out of the box. Any server side component that can generate JSON ( or other supported serialization methods ) will work. You could use PHP on the server side, or bash shell scripts, it doesn't matter to the Javascript code that is generated by GWT.
Yes, it can be practical. I use Rails as my backend and GWT/GXT as my frontend. I love every bit of it! I couldn't stand worrying about browser incompatibilities, so GWT/GXT was a real joy. Also, I had already started my backend in Rails and did not have much experience with Java on the server, so I stuck with Rails.
You may want to take a look at an appropriate GWT Rest framework, as you won't be using RPC.
As an aside, there is one exception where you should use Java on the server. That's if you want to use Google App Engine.
Feel free to ask me any specific questions and I'll be happy to help you out.
Good Luck.
-JP