How exactly does runrev for ipad/iphone work?

Randall Lee Reetz randall at randallreetz.com
Fri May 7 14:38:05 EDT 2010


Thank you robert.

Now anyone want to discuss the advantages, disadvantages, and technical feasibility of rev outputting C source.

Lets start with the fact that the best compilers are written for C.  That these compilers are industry standards and that it could be argued, the epicenter of computing.

I think xtalk is a more human environment for the writing of logic, and that C is that same thing for computers them selves.

A match made in heaven!  Create in rev, test, prototype, deploy in casual situations, and then when everything is ready for the big leagues (or when nothing else is possible) export C source (customized as per target platform).

At this point, pay runrev what their efforts are worth... A lot!  Enter into an equity sharing contract or pay a big publishing fee.  Everyone is happy.

Randall 

-----Original Message-----
From: Robert Mann <rman at free.fr>
Sent: Friday, May 07, 2010 5:21 AM
To: use-revolution at lists.runrev.com
Subject: Re: How exactly does runrev for ipad/iphone work?


Man.. let us read... 

3.3.1 — Applications may only use Documented APIs in the manner
   prescribed by Apple and must not use or call any private APIs.
   Applications must be originally written in Objective-C, C, C++,
   or JavaScript as executed by the iPhone OS WebKit engine, and
   only code written in C, C++, and Objective-C may compile and
   directly link against the Documented APIs (e.g., Applications
   that link to Documented APIs through an intermediary translation
   or compatibility layer or tool are prohibited).

Let's start reading ... A few definitions : 

API's - is an interface implemented by a software program which enables it
to interact with other software (same language or foreign languages).

PLease note that the 3.3.1 DOES NOT state documented API by Apple!! and
refers to PRiVATE APIs.
Litterally speaking PUBLIC APIs like google maps etc.. do not fall in!! 

There are some feras expressed that an expanded interpretation of this
clause would embrace all forms of organized libraires writen in C or C++
that could be incorporated by a programmer to better structure his program.
I cannot see how this interpretation can hold. As well as I cannot
understand the fuss about "ORIGINALLY WRITTEN in c.." because this is
unenforceable legally...

I guess that "Originally written" in Steve's mind means in that context
"hand" written, not just output by a machine...

But, from a legal point of view nobody can restrain the way you think, work,
produce your code. Steve cannot forbid the use of any form or helping tool,
3rd party documentation, copying/pasting of functions from here or there, or
software robot, intermediate layer, provided it delivers some x code :
nobody can restrain this freedom.

The copyright law protects only the materialization of ideas, never the
ideas themselves, nor the processes, not the methods. And programming has
been clearly associated to writing. So nobody (even Stevie..) can (LEGALLY -
ei enforceable in court) dictate how the hell you produce your damned x Code
libraries. 

So I  support the argument that the only way that "originally written in c"
can be interpreted is "at some stage materially visible and editable in C or
C++ in the XCode environment" whatever steps have occured before, as these
prior steps are immaterial.

The limit would be if for instance revMobile produced X Code in two parts :
a) the actual stack application code and b) alongside a set of home made
runrev librarires writen in C or C++ that would be neccessary, part A)
calling part b). My conviction is that even in that situation, a legal
action by Apple would not succeed on the ground of 3.3.1. 

But I guess anyhow Apple has a full discretionnary power to allow apps or
not in their APP store, SO FAR, so yes they could easily tell "your app uses
a set of runrev libraries we de not like.. It is likely you use runrev as a
production tool and we do not like it.. be bye!" Or tell you nothing, just
NO!

But I cannot see "them" as plain evil, just like that. They seem to have
plans for the future and have reasons to enforce the c++ or c and Xcode
compiler. But they do not seem to have any interest to go further than that


More information about the use-livecode mailing list