How exactly does runrev for ipad/iphone work?

Robert Mann rman at free.fr
Fri May 7 08:21:02 EDT 2010


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.

SO personnaly, as a member of the mobile rev alpha program I would not throw
my coin at Kevin if he announced such a direction to be taken, with or
without steve's consent, if there is a possibility technically.

In practice though, I'm getting ready to byte at xcode straight from the
box, this summer, because, I do not want to wait infinitely until we have
the perfect tool and I would also welcome Kevin if he told us that he just
stopped the revMObile iphone program with a compensation for early buyers.
It might well be the most reasonnable course to take.

I would welcome a correlative annoucemet to focus BACK on  ON-REV to produce
an actual alternative to PHP, with .irev stacks that would allow selling
libraries and developping this market, on which runrev could really shine...
and where runrev would stand clear of Steve's fears.. 

I appreciate and supported the mobile rev venture, but I really ask Kevin
and runrev as a whole in the interest of all parties to cover for the secure
grounds before going to battle in a new adverse territory.

-- I am deceived with the ON-REV stand still situation making it impossible
(unless using old CGI) to install on-rev on 3rd parties servers and market
private libraires. And it seems much more within reach to me than
re-engeeneering revMobile, that can still be used for vertical professionnal
apps not sold in the AppStore.

-- I really suffered with the AUDIO ( I mean the lack of audio libraires, in
runrev..) I found solutions but quicktime lib + lame lib but could not
complete project due to lack of basic mix libraries (fade in out, simple
mixin transition). So anyway.. solution seems to go Xcode direct.. 

Hugh!











-- 
View this message in context: http://runtime-revolution.278305.n4.nabble.com/How-exactly-does-runrev-for-ipad-iphone-work-tp2133661p2134074.html
Sent from the Revolution - User mailing list archive at Nabble.com.



More information about the use-livecode mailing list