Is it possible to use rsync inside of iOS app? - iphone

is it possible to use rsync lib inside of an iPhone or iPad app? Or maybe there are any alternatives suitable for remote file sync over sftp?

Acrosync library is a good choice, and I have made a demo for it.
It is licensed under the RPL license, and commercial license are provided.
Repository:
https://github.com/gilbertchen/acrosync-library
My demo (fixed some bugs):
https://github.com/Lessica/Acrosync-Demo

acrosync seems to be worth checking out as it implements a rsync client library rewritten from scratch and is available on multiple platforms, including iOS.
https://acrosync.com/library.html

I have to close this question because at the moment there are only few possible solutions and neither of them runs 'out of the box'.
I have found several programs on the AppSote which somehow mimics rsync functionality so after all using rsync is possible, however not so simple as it seems.
Modifiying rsync to turn it into a library is feasible, but this is not how author of one of these programs did it. Doing so would subject app to GPL, which not permitted by Apple.
There are other approaches, such as http://search.cpan.org/~leakin/File-Rsync-0.42/Rsync.pm (a perl module), and https://github.com/kolosy/rsync.net (c#).
I doubt someone would really need rsync lib for iphone since iOS 5.0 was released. However one may need it to support some legacy code, but even then rewriting rsync lib from scratch is questionable, because it is complex tool and this task certainly will take more than two or three month.

Related

Building a professional application in Perl?

I've built a set of tools I use in my day-to-day work and I would like to make them look a bit more "professional" in order to sell them to financial institutions.
At the moment these tools are written in Perl and are executed from a DOS command line, it's extremely efficient but it doesn't look very attractive.
So, I would like to add a user interface to it but I don't really know what to use for language knowning that :
A Perl CGI interface hosted on the web is not an option since the information to be given as input is quite sensitive.
It would be ideal to sell it as a package/executable.
I don't really like the Perl/Tk interface.
I'm ok with rewritting the application in another language but I would prefere to reuse the main modules in Perl since it's very powerful with regular expressions and lists/arrays.
What would you advise me to do ?
Thanks,
Lory
If you want a non-web-based GUI, and don't like Tk, there's also Wx, which is a wrapper for the wxWidgets GUI toolkit.
However, web applications nowadays can be really easy to create (using a modern framework). Take a Mojolicious application, for example: Mojolicious carries no dependencies other than Perl 5.12.x, and provides its own web server (Hypnotoad). You can start by generating a "Lite::App", which is a simple self-contained single-file application, and then grow it to a bigger distribution later on as the need arises. It even comes with tools to convert your application to a conveniently packaged distribution that can be installed as easily as any CPAN module.
So that leaves the issue of security. User authentication, IP whitelisting, local network only... there are many ways to make a web application "for internal use only" if that's what you need.
You might just throw together a web-application prototype, and once you determine customer interest in your product, invest the substantial time in writing it as a Windows GUI application.
Continuing on from DavidO's answer, because the current web microframeworks for Perl (I prefer Dancer over his suggestion of Mojolicious, but both are good and largely equivalent) contain their own bundled web mini-servers, they also allow for the app to easily run entirely on the local machine.
Since these mini-servers default to a non-standard port (usually 3000 or 5000) by default and you can easily set them to a different port, they can be isolated by firewalls relatively easily, ensuring that nobody can connect to them remotely. You can also, of course, include and IP address check in the app and have it reject any requests that don't originate from localhost.
My guess is that the target system will be Windows. Use a RAD (Rapid Application Development) platform to develop a GUI. Examples for such a platform are Delphi or .NET with C# or VB. For bundling the Perl part, consider using a tool called perl2exe.
It doesn't sound like your scripts should require a web server. Also, consider the installation hassle. Only guessing as you're not giving much information about what your scripts are doing.
I am using the Cava packager to deploy my Perl-written tools. You can even generate an installer executable with just some mouse-clicks. It works pretty well with strawberry Perl and wxPerl on Windows.

Executing prolog code on an iPhone

I currently have the need to execute prolog code in an application I am making. I am aware that Apple probably never would allow something like this in the App Store, but that is not the intention either. This is more a private project that will never reach the App Store.
Purpose
In this case prolog is used to describe an object (like for example a telephone) and its properties. The object will be drawn with OpenGL using coordinates specified in the prolog script. The reason for using prolog is that I need the ability to query the program about some of the features this object has, and prolog eases this a lot. Bottom line: I "need" to query a prolog script from my app.
Possible solutions
Embed an already existing implementation written in C. I am unsure if this will even work.
Execute the prolog code on another machine and use the network to query prolog.
It seems that it is possible to run some sort Ruby VM inside the app (shinycocos uses this as far as I understand), could this be used to run one of the Ruby Prolog implementations?
Find some alternative to Prolog. This needs to give me some of the same possibilities I get with prolog.
Sadly, google gives me close to no results at all, so I have a feeling that I might be quite alone on this project. If anyone have any experience or clue at all, I would be very thankful.
Having faced similar difficulties calling prolog code, albeit in a different situation, I'd recommend checking out the castor c++ library. This allows you to write logic paradigm code in native c++ without needing to extend the language at all. As castor is a header only library it is easy to compile wherever c++ is available.
Castor website: http://www.mpprogramming.com/cpp/default.aspx
Half a year later, I would just like to provide some insight on this. I ended up writing a server with an interface to prolog in Java, accepting prolog calls through TCP. It works almost exactly like the live prolog interpreter SWI-prolog (among others) provides, and mostly works quite well. However, it is far from an optimal solution, as you can't call functions from inside prolog. You lose the possibility of having two-way communication.
If I were to start all over again, I would certainly have tried harder to compile one of the pure C implementations for iOS. I gave it a quick go, but my lack of experience stopped me from even removing all of the errors I got. Judging by the fact that you cannot have prolog running as a background process on a unmodified version of iOS as well, some major rewriting would have to be done. Because of this, one might just have to write a new implementation (perhaps inspired by some of the more lightweight ones out there) from scratch to get the perfect solution.
You can download SWI-Prolog's source code and compile it with XCODE for iOS platform. I've never done that, but it's certainly technically possible.
Once you do that, there are a lot of examples on how to run prolog code from C/C++, hence, you will be able to run prolog from Objective-C.
FYI, you can quite easily bi-directionally make calls between Java and SWI-Prolog if you use JPL:
http://www.swi-prolog.org/packages/jpl/
It is also fully re-entrant, so you can instantiate prolog code from java, which in turn instantiates java code etc...
I did this for a number of commercial projects a few years ago when I was required to connect a Prolog based Reasoning Engine to a lot of Java code.
It does use JNI (the Java Native Interface), so you need to be careful about how you compile and link to the native api. Though if you compile it appropriately for each platform you can make it work cross platform. I had it working on OS-X, Windows, Linux & Solaris.
I do not know if this has been tried but there is the possibility to use the combination of NodeJS for Mobile Apps & TauProlog:
https://code.janeasystems.com/nodejs-mobile
https://github.com/JaneaSystems/nodejs-mobile
and
http://tau-prolog.org/

How to code sharing between Android and iOS

I'm moving away from strict Android development and wanting to create iPhone applications. My understanding is that I can code the backend of iOS applications in C/C++ and also that I can use the NDK to include C/C++ code in Android apps. My question however is how? I've googled quite a bit and I can't find any clear and concise answers.
When looking at sample code for the NDK, it seems that all the function names etc. are Android (or at least Java) specific and so I would not be able to use this C/C++ backend to develop an iPhone frontend?
I'd appreciate some clarification on this issue and if at all available some code to help me out? (even just a simple Hello World that reads a string from a C/C++ file and displays it in an iOS and Android app).
Thanks guys
Chris
Note that I almost exclusively work on "business/utility/productivity" applications; things that rely heavily on fairly standard UI elements and expect to integrate well with their platform. This answer reflects that. See Mitch Lindgren's comment to Shaggy Frog's answer for good comments for game developers, who have a completely different situation.
I believe #Shaggy Frog is incorrect here. If you have effective, tested code in C++, there is no reason not to share it between Android and iPhone, and I've worked on projects that do just that and it can be very successful. There are dangers that should be avoided, however.
Most critically, be careful of "lowest common denominator." Self-contained, algorithmic code, shares very well. Complex frameworks that manage threads, talk on the network, or otherwise interact with the OS are more challenging to do in a way that doesn't force you to break the paradigms of the platform and shoot for the LCD that works equally badly on all platforms. In particular, I recommend writing your networking code using the platform's frameworks. This often requires a "sandwich" approach where the top layer is platform-specific and the very bottom layer is platform-specific, and the middle is portable. This is a very good thing if designed carefully.
Thread management and timers should also be done using the platform's frameworks. In particular, Java uses threads heavily, while iOS typically relies on its runloop to avoid threads. When iOS does use threads, GCD is strongly preferred. Again, the solution here is to isolate the truly portable algorithms, and let platform-specific code manage how it gets called.
If you have a complex, existing framework that is heavily threaded and has a lot of network or UI code spread throughout it, then sharing it may be difficult, but my recommendation still would be to look for ways to refactor it rather than rewrite it.
As an iOS and Mac developer who works extensively with cross-platform code shared on Linux, Windows and Android, I can say that Android is by far the most annoying of the platforms to share with (Windows used to hold this distinction, but Android blew it away). Android has had the most cases where it is not wise to share code. But there are still many opportunities for code reuse and they should be pursued.
While the sentiment is sound (you are following the policy of Don't Repeat Yourself), it's only pragmatic if what you can share that code in an efficient manner. In this case, it's not really possible to have a "write once" approach to cross-platform development where the code for two platforms needs to be written in different languages (C/C++/Obj-C on iPhone, Java for Android).
You'll be better off writing two different codebases in this case (in two different languages). Word of advice: don't write your Java code like it's C++, or your C++ code like it's Java. I worked at a company a number of years ago who had a product they "ported" from Java to C++, and they didn't write the C++ code like it was C++, and it caused all sorts of problems, not to mention being hard to read.
Writing a shared code base is really practical in this situation. There is some overhead to setting up and keeping it organized, but the major benefits are these 1) reduce the amount of code by sharing common functionality 2) Sharing bug fixes to the common code base. I'm currently aware of two routes that I'm considering for a project - use the native c/c++ (gains in speed at the expense of losing garbage collection and setting targets per processor) or use monodroid/monotouch which provide c# bindings for each os's platform functionality (I'm uncertain of how mature this is.)
If I was writing a game using 3d I'd definitely use approach #1.
I posted this same answer to a similar question but I think it's relevant so...
I use BatteryTech for my platform-abstraction stuff and my project structure looks like this:
On my PC:
gamename - contains just the common code
gamename-android - holds mostly BatteryTech's android-specific code and Android config, builders point to gamename project for common code
gamename-win32 - Just for building out to Windows, uses code from gamename project
On my Mac:
gamename - contains just the common code
gamename-ios - The iPhone/iPad build, imports common code
gamename-osx - The OSX native build. imports common code.
And I use SVN to share between my PC and Mac. My only real problems are when I add classes to the common codebase in Windows and then update on the mac to pull them down from SVN. XCode doesn't have a way to automatically add them to the project without scripts, so I have to pull them in manually each time, which is a pain but isn't the end of the world.
All of this stuff comes with BatteryTech so it's easy to figure out once you get it.
Besides using C/C++ share so lib.
If to develop cross-platform apps like game, suggest use mono-based framework like Unity3D.
Else if to develop business apps which require native UI and want to share business logic code cross mobile platforms, I suggest use Lua embedded engine as client business logic center.
The client UI is still native and get best UI performance. i.e Java on Android and ObjectC on iOS etc.
The logic is shared with same Lua scripts for all platform.
So the Lua layer is similar as client services (compare to server side services).
-- Anderson Mao, 2013-03-28
Though I don't use these myself as most of the stuff I write won't port well, I would recommend using something like Appcelerator or Red Foundry to build basic applications that can then be created natively on either platform. In these cases, you're not writing objective-c or java, you use some kind of intermediary. Note that if you move outside the box they've confined you to, you'll need to write your own code closer to the metal.

Does anyone has first-hand experience with G-WAN web Server?

The only place where I found informations on G-WAN web server was the project web site and it looked very much like advertisement.
What I would really know is, for someone who is proficient with C, if it is as easy to use and extend that other architectures. For now I would mostly focus on scripting abilities.
Are C scripts on GWAN easy to write ?
Can you easily update and upload new C scripts to the server (say as easily than some PHP or Java pages on other architectures) ? Do you have to restart the server when doing so ?
Can you easily extend it with third party or existing C libraries ?
Any other feedback welcome.
Well, now G-WAN is available under Linux, I am using it for more than 6 months.
The C scripts are fully-ANSI C compatible so there is no difference for any seasonned C programmer.
To update them on the server, you can edit them directly in the /csp folder (remotely via SSH) or locally on a test machine (and copy them later): G-WAN reloads scripts on-the-fly when they have been changed on disk (no server stop required).
G-WAN C scripts can use any existing library (starting with all those under /usr/lib) without any configuration or interface: you just have to write a '#pragma link' followed by the name of the library at the top of your script.
What I found really useful is the ability to edit C scripts and refresh the view in the Internet browser to see how my code works.
If there is a compilation error, then G-WAN outputs the line in the source code (just like any C compiler).
But where it enters the extraordinary area, is when you have a C script crash: here also it gives you THE LINE NUMBER IN THE SOURCE CODE (with the faulty call and the backtrace).
Kind of black-magic when you are used to Apache modules.
My experience with G-WAN and its C scripts are:
The G-WAN community is very small. Questions you have are mostly answered by its single developer.
I consider the API not mature: it's not as "clean" as Java APIs.
The limitation, but at the same time the power, of C: it's a systems programming language. So writing application logic in it must be done carefully.
You generally need to be a good developer to get good results: if you do something wrong, the server crashes fast and hard (Unix-style).
I've written some scripts now, to try out G-WAN. Overall, it's been very "productive": not much bugs and it works if you follow the guidelines and don't want to do too much funky stuff you expect it to have, like mature web servers. However, I have got the feeling I'm reinventing the wheel a lot of times.
G-WAN also support scripts written in other programming languages (C++, Objective-C, Java, etc.) so you will benefit from whatever native libraries each language implements.
For C scripts, well, the /usr/lib directory lists more than 1,500 libraries that G-WAN can re-use with a simple #pragma link "library".
I found it neat to be able to write a Web application with a part in C, another in C++ and a third one in Java!
Benchmark shown how G-wan fare poorly at handling these tests.
http://joshitech.blogspot.sg/2012/04/performance-nginx-netty-cppcms.html
I have been using G-Wan for about two years. I consider it highly stable and production ready for static files. I have a number of static sites running for over a year with no issues.
I have built some small scale dynamic sites in C with it as demos/test projects. A bittorrent tracker and a real time analytics platform both using the KV Store for data backing.
In my view building large scale dynamic sites in G-Wan is possible but only with a significant investment in development and support. G-Wan is better suited to building robust highly scalable "enterprise grade" applications than tossing something together over a weekend.
I use G-Wan for a CMS http://solicms.com but for now, I use Ruby as primary language.
I have used G-wan for some preliminary testing and it does benchmark well. I have found a few points of concern that make it so that I will not likely use it for any of my projects. I have found that it seems to cache responses for about 0.5secs to speedup the responses/second and I can't have only some of the responses hitting the application code. Also the key/value store is great for cache and temporary data storage but I'm not sure how well it will work as a real back-end storage method.

Do you need a framework to write Ruby or Python code for the web?

Every time I see Ruby or Python discussed in the context of web development, it's always with a framework (Rails for Ruby, Django for Python). Are these frameworks necessary? If not, is there a reason why these languages are often used within a framework, while Perl and PHP are not?
I can only speak towards Ruby - but, no, you don't need a framework to run Ruby based pages on the web. You do need a ruby enabled server, such as Apache running eruby/erb. But, once you do, you can create .rhtml files just like RoR, where it processes the inline ruby code.
The short answer is no, they are not necessary. In ruby you have .erb templates that can be used in a similar way as you use PHP pages. You can write a site in ruby or Python using several technologies (Rails-like frameworks, Templates or even talking directly with the HTTP library and building the page CGI-style).
Web frameworks like Python's Django or Ruby's Rails (there are many) just raise the level of abstraction from the PHP's or ASP's, and automate several process (like login, database interaction, REST API's) which is always a good thing.
"Need" is a strong word. You can certainly write Python without one, but I wouldn't want to.
Python wasn't designed (like PHP was, for example) as a direct web scripting language, so common web-ish things like connecting to databases isn't native, and frameworks are handy.
EDIT: mod_python exists for Apache, so if you're merely looking to write some scripts, then Python doesn't need a framework. If you want to build an entire site, I'd recommend using one.
From a Pythonic point of view, you'd absolutely want to use one of the frameworks. Yes, it might be possible to write a web app without them, but it's not going to be pretty. Here's a few things you'll (probably) end up writing from scratch:
Templating: unless you're writing a really really quick hack, you don't want to be generating all of your HTML within your Python code -- this is a really poor design that becomes a maintainability nightmare.
URL Processing: splitting a URL and identifying which code to run isn't a trivial task. Django (for example) provides a fantastic mechanism to map from a set of regular expressions to a set of view functions.
Authentication: rolling your own login/logout/session management code is a pain, especially when there's already pre-written (and tested) code available
Error handling: frameworks already have a good mechanism in place to a) help you debug your app, and b) help redirect to proper 404 and 500 pages.
To add to this, all of the framework libraries are all heavily tested (and fire tested). Additionally, there are communities of people who are developing using the same code base, so if you have any questions, you can probably find help.
In summary, you don't have to, but unless your project is "a new web framework", you're probably better off using one of the existing ones instead.
Framework? Heck, you don't even need a web server if you're using Python, you can make one in around three lines of code.
As to the why:
The most plausible thing I can think of is that Perl and PHP were developed before the notion of using frameworks for web apps became popular. Hence, the "old" way of doing things has stuck around in those cultures. Ruby and Python became popular after frameworks became popular, hence they developed together. If your language has a good framework (or more than one) that's well supported by the community, there's not much reason to try to write a Web App without one.
A framework isn't necessary per se, but it can certainly speed development and help you write "better" code. In PHP, there are definitely frameworks that get used like CakePHP, and in Perl there are many as well like Mason and Catalyst.
The frameworks aren't necessary. However, a lot of developers think frameworks ease development by automating a lot of things. For example, Django will create a production-ready backend for you based on your database structure. It also has lets you incorporate various plugins if you choose. I don't know too much about Rails or Perl frameworks, but PHP frameworks such as Zend, Symfony, Code Igniter, CakePHP, etc are used widely.
Where I work at we rolled our own PHP framework.
Are these frameworks necessary?
No. They, like any 'framework', are simply for speeding up development time and making the programmer's job easier.
If not, is there a reason why these languages are often used within a framework, while Perl and PHP are not?
PHP and Perl were popular languages for building web sites well before the idea of using frameworks was. Frameworks like Rails are what gave Ruby it's following. I'm not sure that Python or Ruby were that common as web languages before they were backed by frameworks.
These days, even PHP/Perl web developement should be backed by a framework (of which there are now many).
By no means are those development frameworks required. But as with most development environments, your productivity will increase exponentially if you have a supported framework to reference and build your applications on. It also decreases the training needed to bring others up to speed on your applications if they already have a core understanding of the framework that you use.
For python, the answer is No you don't have to. You can write python directly behind your web server very easily, take a look at mod_python for how to do it.
A lot of people like frameworks because they supply a lot of the boilerplate code in a reliable form so you don't have to write it yourself. But, like any code project, you should choose the tools and frameworks on their merit for your problem.
You can certainly write CGI scripts in either language and do things "raw".
The frameworks (ideally) save the trouble of writing a pile of code for things that other people have already handled (session handling, etc.).
The decision probably comes down to what you need to do. If the framework has the features you need, why not use it. If the framework is going to require extensive modifications, it might be easier to roll your own stuff. Or check out a different framework.
The python library has numerous modules for doing cgi, parsing html, cookies, WSGI, etc:
http://docs.python.org/library/index.html
PHP has a lot of frameworks. Probably more then most. In Ruby most use Rails so thats what you hear, and Django for Python is mentioned more then not.
But with PHP you have many to choose from.
List of web application frameworks
Any language that can "print" can be used to generate web pages, but frameworks handle a lot of the HTML generation for you. They let you concentrate more on the content and less on the details of coding the raw HTML.