With Mac OS X Server's included (or freely available) tools, a background in Objective-C and some rusty familiarity with scripting languages...how might one go about "easily" employing RESTful JSON services under Mac OS X Server?
This is mostly for prototyping so simplicity and GUI tools are appealing though not at the expense of a robust foundation.
Edit: Tickling this to see if anything's changed with Snow Leopard
Consider using simply Apache + PHP. Stable, fast, tons of knowledge and examples out there. And you may already have it running on your server.
PHP has a c'ish syntax and is easy to pick up.
See this for help in getting it running: http://foundationphp.com/tutorials/php_leopard.php
It really depends on your benchmark for "simple". With OS X Server, you have a lot of choices:
Use WebObjects, if you want to leverage your skills with Objective-C (or even Java, for that matter, if you know Java).
Use PHP... Apache and PHP are built in.
Use Python and Django/TurboGears/Twisted/Plone/WSGI/ModPython.
Use Ruby and Rails.
Use Perl and CGI... or any language and CGI, for that matter.
Use Java and Tomcat.
Use Java and Tomcat + JBoss.
It's both a blessing and a curse, in your case, that OS X Server supports almost anything. Heck, you could almost even patch CGI to AppleScript if you wanted to (aside: I'm sure we both just cringed at that :-) ). There are a lot of built-in, free, options with OS X (Client) and OS X (Server).
PHP may seem your easiest choice for the default install of Apache and its configuration, but Ruby/Rails or Python are almost as readily available out-of-the-box.
Related
I'm having issues looking for a rack supporting webserver in Ruby that meets our requirements. What we've coded already is using Sinatra, so that's what we're aiming to run.
The webservice must:
Run in JRuby
Support SSL
support streaming of files. It's much more important to be memory-efficient than performant.
Be Multiplatform (Windows and Linux flavours)
As lightweight as possible - links back to memory efficiency
We're currently using WEBrick, but it can't handle streaming, so we're looking for alternatives. I've been looking around myself, but I'm having real difficulty finding documentation about what various rack webservers can and can't do. The services I've looked at are:
WEBrick - doesn't support streaming
Thin - depends on C code, so doesn't run in JRuby
Passenger - ditto Thin (C Code)
Unicorn - ditto Thin (C Code)
We're aware that it could be deployed J2EE container, but as that would require distributing the container around with it, we'd rather not go down that approach if we can avoid it (as it would be a heavier weight solution).
Thanks in advance for any help people can give.
Does Puma meet your requirements? It supports JRuby, SSL, Windows + Linux, and advertises itself as lightweight. I'm afraid I haven't tried it out, nor do I know if it streams files.
For anyone who finds this question and wants to know what we used in the end: we went with Trinidad as it met all the requirements we needed.
It was quite a simple job to strip out the original WEBrick server we were using and replace it with Trinidad, while still using Sinatra. We then used JRuby to wrap it all up into a Jar and run it in the JVM as a self contained web-service package.
I've seen download manager programs including IDM taking control of downloads in browsers without having extensions in them and they are calling it (Advanced Browser Integration).
I was wondering if anyone can suggest an approach for a similar situation?
IDM only works on Windows and does his Advanced Browser Integration tricks using Windows Filtering Platform which is a windows specific service.
If you want to do something similar on Windows, you should study that platform.
On unix systems, as far as I know, there isn't anything like the Windows Filtering Platform. Packet filtering and other firewall like functionality happens in the kernel and there are multiple implementations of that: which is running (if any) depends on how the user decided to configure the system (even if ipf is almost guaranteed to be the used one on BSD and BSD derived systems).
On Mac Os X specifically you probably want to check Network Kernel Extensions. I'm not sure they are sufficient to do what you want to do, but I suspect they are.
I saw that the Clang 3.0 port includes Objective-C as a development language, and furthermore, I also found this port "libobjc2-1.6" (Replacement Objective-C runtime supporting Obj-C 2 features) and "ofc-0.8.1_5" (The Objective-C Foundation Classes library).
Let's say we are considering to use Objective-C on FreeBSD to develop a web-based application (vs. using Java and running it on Tomcat/Glassfish), how do we approach it?
Does Objective-C development actually work on FreeBSD (9.0)?
What are the things (frameworks/library) to download and install?
What IDE?
As I mentioned that let's say we intend to develop a web application, what are the library?/libraries (We also saw that there is "GNUstepWeb" - successor to WebObjects - is this the web library we should consider? Is this the ONLY ONE - what about other alternatives? Further, can GNUstep/GNUstepWeb compile under Clang 3.0 or make use of those Objective-C ports ("libobjc2-1.6" and "ofc-0.8.1_5") mentioned above? Are those ports relavant?
Has anyone successfully done a web application project development on FreeBSD using Objective-C (and deployed on FreeBSD)?
Note: Web-based applications means it takes in HTTP (RESTful) calls and talks to a database (for traditional and/or NoSQL databases).
There is http://cocotron.org, a port (more like re-write) of Apple's runtime for Objective-C.
I still could advice against using ObjC for web stack. I did that previously, and I must say that it involves a big chunk of pretty common code that you will need to implement for basic HTTP server functionality.
Also, Cocotron is not really that fast (as a runtime). It's ok for desktop applications, but web world is much more restrictive.
I am writing a library supporting this using FastCGI to interface the server called CGIKit (https://github.com/xcvista/CGIKit) and it works on GNUstep instead of Cocoatron.
you may look at sope and sogo http://sope.opengroupware.org/en/build/thirdparty.html
Someone seems having success building Objective-C program for FreeBSD 9.x
You don't need to worry about the IDE if you don't mind using Apple. It would be possible to write on Mac, and run on FreeBSD. (personally I think this is the best of both world) IMO, if there's a server OS with Objective-C ready, FreeBSD will be first one.
More serious problem is libraries and frameworks. We don't have much options in Objective-C for web server development even on OSX. But we can wrap existing C/C++ libraries, (just as like many great node.js, Python, Ruby libraries do) and I think we may can get bunch of options with small efforts.
Some people worry about security. And I always wonder how many foundational programs on the network are written in C/C++ and other languages.
In his blog post “Using Objective-C on the server” Graham Lee describes how to set up a minimal GNUStep-WebApp. Obviously, the build instruction for GNUstep-make would differ, but other than that this seems like a nice starting point.
He wrote several other posts (jQuery, AJAX) further exploring GSW.
I'm writing software for a new hardware device which I want any kind of new third-party application to be able to access if they want to.
The software will be a native process (C++) that should be pollable by 3rd party games and applications that want to support the hardware device. Those 3rd party apps should also be able to receive events from the native process, on a subscribe basis. So aside from the native process, I'll also supply "connector" libraries to the 3rd party developers, for all platforms/languages that they might choose (Java, C++, Python etc.) to embed in their apps so they can easily connect to the device with hardly any extra code needing to be written by them. I want to target all desktop/laptop OS platforms, and have a pretty good idea of what functions I want to expose, but ideally I don't want to be too stuck (i.e. I want it to be elegantly scalable from both client and server perspectives).
I'm looking for reliability going forward, performance, maintainability going forward, and cross-platform/language flexibility going forward, and ease of development, in that order.
What should I use?
CORBA, MessagePack-RPC, Thrift, or something else entirely?
(I've omitted ICE because of it's licensing)
Thrift or Message Pack is the best option going forward. Both are sleek, light weight and do not add much latencies to your process. They have support for most of the common languages, and are in Active Development. At the current stage I would prefer thrift personally but message pack does seem to promise a lot of features.
Thought thrift might not be as windows friendly as we want but people are using it on windows.
This is a starter guide for thrift on windows.
http://wiki.apache.org/thrift/ThriftInstallationWin32
Only installing and getting the Thrift compiler can be troublesome on windows. Using the generated files depend on the language you choose and lot of the languages have good support to run the files by importing thrift libraries. (Java it is very easy, MAVEN artifact)
There is a discussion on the RPC frameworks available at RPC frameworks available?
CORBA according to me is old cumbersome and very heavyweight.
If ancient and heavyweight don't put you off, obsolete definitely should. Regardless, I can tell you what we've been using Google Protocol Buffers at work recently, and they're pretty easy to use.
From the developer's perspective, all you need to do is have a build of GPB (which really isn't that difficult), and then it will generate source files for you. The end result is a cross-platform binary message transport message passing interface (think XML and limited RMI, not MPI-like functionality).
We use it on Windows to talk to an Arm-based Linux system (TS-7200's from embedded arm) running the same software. to my knowledge, it is compatible with many languages.
CORBA is the only free "RPC" thing that would work for my system right now, even though it scales very badly. Thrift isn't Windows-friendly yet. Neither is MessagePack-RPC yet available in all languages and OSs, even though it's still in development. If CORBA was elegantly scalable it probably wouldn't have become obsolete at all.
Protocol Buffers and messaging would work, I'd have to develop a both a client and service implementation for every platform/language. It would also be very scalable. I've decided on this.
I'm currently using Apache Thrift for a Hospital Manager project. It is better than CORBA in many areas, not to mention it is lightweight and much easier to implement and understand. The learning curve for Thrift is definitely subtle compared to CORBA, but the documentation for Thrift is the worst thing.
I'm using a Ruby Thrift server to which Obj-C and Java clients connect. The Thrift parser or "compiler" does a pretty good job generating source files for the languages you want, although it is far too verbose. I would definitely look into implementing Thrift, or Google ProtoBuffs if I was starting a new project, since CORBA is really outdated, and might not implement new technologies in the future, not to mention that there are many vulnerabilities and exploits targeting CORBA that will not get patched since it's not in development anymore, presenting some serious security holes on your new project.
Thrift supports many programming languages: C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Objective-C, JavaScript, Node.js, Smalltalk, OCaml and Delphi as of this writing. Supporting multiple languages is key, I think, for the purpose of your project.
I've been using for more than 12 years PHP with Apache (a.k.a mod_php) for my web
development work. I've recenlty discovered python and its real power (I still don't understand why this is not always the best product that becomes the most famous).
I've just discovered mod_python for Apache. I've already googled but without success things like mod_python vs mod_php. I wanted to know the differences between the two mod_php and mod_python in terms of:
speed
productivity
maintainance
(I know `python is most productive and maintainable language in the world, but is it the same for Web programming with Apache)
availability of features e.g, cookies and session handling, databases, protocols, etc.
My understanding is that PHP was designed with Internet/Web in mind, but Python is for a more general purpose.
Now most people are leaving mod_python for mod_wsgi, which is more robust and flexible.
To answer other questions:
speed: python is faster. (PHP is slower than both ruby and python)
productivity: at least the same as php with numerous libraries
maintenance: python is clear and neat
features: more than you need, I would say.
Python was not popular on web because it wasn't focused on web at all. It has too many web frameworks (more frameworks than programming languages), so the community has not been as strong as Ruby on Rails.
I wanted to know the differences between the two mod_php and mod_python...
PHP is more widely available on Internet hosts than Python.
I've noticed on one of my Python web sites that if I'm the first user to use Python, on that Internet host, the start up time of the Python services can be measured in minutes. Most people won't wait minutes for a web page to pop up.
Python has the same web features (cookies, session handling, database connections, protocols) as PHP.