How exactly does runrev for ipad/iphone work?

[Randall Reetz]

One way to do this is the old runrev virtual machine idea (build and distribute a rev stack player app for iphads).  The world's legal systems protect (US first amendment) free speech and content authorship such that source content can not be messed with or restricted to or tied to exclusive protocol.  No one can tell William Shakespeare what type of pen he can write with or printing presses he can publish with.  

Apple has walked a fine line here for years.  In the world of sound recordings, there has always been enough purchasing venues (record stores) to provide the requisite freedom of expression and publication.  But when Apple ties content source to player they are violating the same laws that worked against Microsoft's browser integration scheme.  What apple used to get away with when it was the little guy no longer applies now that they dominate the media player landscape.

Randall Reetz


On May 6, 2010, at 11:28 AM, Randall Reetz wrote:

> So, is Apple demanding that the use of its blessed environment is contingent on purchase (of said)?  If not, there must be some way to build the rev stack to iphad app work flow such that rev developers are both within Apple's requirements and are protected from the complexity happening behind the scenes.
> 
> Randall
> 
> 
> On May 6, 2010, at 11:19 AM, Richard Gaskin wrote:
> 
>> Randall Reetz wrote:
>> 
>>> Is there a resource online or a white paper that describes in basic
>>> language how runrev for mobile (specifically for apple products)
>>> works?  Does it use apple's blessed dev environment at any step in
>>> the process?  In what form are the final builds?  Does it require a
>>> player app to be installed on each devise?  In short, how does runrev
>>> for mobile differ architecturally from the fully blessed apple
>>> environment and app format?
>> 
>> The last build RunRev shared with its early adopters worked in a way that was compliant with the license terms in force at the time they started that investment, but which has since become redefined by Apple as verboten:
>> 
>> You wrote in RevTalk, which the engine then compiled down to a form of object code that would run well on the iPhone with no player and no interpreted code.
>> 
>> But under the rules in effect as of 11:19AM this morning (which may change again by this afternoon), one of the unprecedented elements of the license is that Apple limits not only the state of the deliverable object code, but also the provenance of the source code:
>> 
>> 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).
>> 
>> For more on this provenance aspect see Hank Williams' post:
>> <http://whydoeseverythingsuck.com/2010/04/jobs-bans-non-c-libraries-insane.html>
>> 
>> The "must be originally written in" clause is the killer here.  Even translating RevTalk to generate C/C++/Objective-C code which was fully compliant with all technical aspects and in all ways indistinguishable from human-written code would be punishable under criminal law.
>> 
>> Whether using psuedocode during design, as is a common practice, also violates this clause has yet to be tested.
>> 
>> 
>>> What are the current plans and how have they changed runrev's
>>> previous plans for the revmobile product's base architecture
>>> and release protocols?
>> 
>> Currently unknown.
>> 
>> Kevin has noted here that he is in negotiations with Apple to determine the best course of action in light of their sweeping and unexpected change, and will report back here as soon as the outcome is known.
>> 
>> As currently written, Apple's current iPhone license agreement seems to leave only four options available to developers:
>> 
>> 1. Developing using Apple APIs in only C/C++/Objective-C; because
>>  of the unusual provenance clause this option does not appear
>>  to be available to RunRev at this time.
>> 
>> 2. Develop using JavaScript and WebKit; possible for RunRev, but
>>  while some of us do a bit of that in very limited ways it would
>>  no doubt be very costly to generate JS from the whole of RevTalk
>>  (though Toolbook kinda did that in a useful way).
>> 
>> 3. Develop for the rest of the world and wait for Apple to change.
>> 
>> 4. Develop for the rest of the world, and for iPhone OS deploy only
>>  for "in-house" use under the special provisioning rules that
>>  allow it, bypassing the AppStore.
>> 
>> I've seen nothing in the license or discussion of it which suggest there is a fifth option; at least any fifth option that doesn't leave developers even more exposed to risk than they already are.
>> 
>> I'm confident Kevin will choose from the limited options Apple has provided its developers the one that's in the best interest of this customers.
>> 
>> --
>> Richard Gaskin
>> Fourth World
>> Rev training and consulting: http://www.fourthworld.com
>> Webzine for Rev developers: http://www.revjournal.com
>> revJournal blog: http://revjournal.com/blog.irv
>> 
>> 
>> _______________________________________________
>> use-revolution mailing list
>> use-revolution at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-revolution
>> 
> 
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
>