cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian LeRoux...@brian.io>
Subject Re: adding 'browser' as a platform for cordova.js
Date Tue, 10 Dec 2013 00:19:21 GMT
Quick update. We have a repo for this:

https://git-wip-us.apache.org/repos/asf?p=cordova-browser.git



On Tue, Dec 10, 2013 at 9:32 AM, Brian LeRoux <b@brian.io> wrote:

> Answers to Jesse inline (and should answer other queries too).
>
>
>
>> Interesting.  Can you elaborate on use-cases that this would make sense
>> for?
>>
>>
> In order of selfish priority.
>
> - Browser targeted deployment (an original goal of that PhoneGap thing we
> based our efforts on)
> - Surfacing platform incompatibilities from web browsers (such as page
> visibility api vs our pause/resume thing)
> - Simplest possible reference implementation for future platform targets
> (ideally)
> - Optimizing cordova.js (the size for exec/parse not an issue so much as
> the size indicates waste)
>
>
>
>> It is acceptable that cordova_plugins.js does not exist, as this should be
>> caught, and recovered from in all platforms.  Yes, this file will be
>> created when any plugin is added.
>>
>>
> Cool. I created a bug for this. [1]
>
>
>
>> The code you posted is essentially the FirefoxOS exec code, which is
>> essentially the Windows8 exec code, maybe we should just make this a
>> default exec.
>
>
> I am all for consolidating them into the smallest possible implementation.
>
>
>  >>
>> >> Should we consider deprecating pause/resume for page visability api?
>> >>
>> > Makes sense to me.
>>
>> I think there is still value in having a distinction between the 2.  It
>> may
>> make sense for the browser to use visibility to trigger pause/resume, but
>> I
>> don't think native platforms should necessarily.  Worth some
>> experimentation and more discussion though.
>>
>
> I'll start a thread. Would like to dig into this thinking.
>
>
> Re: size of the file. There are several optimizations we could add, but as
>> part of packaged apps, load time has not seemed to be an issue in awhile.
>> Measurement should come first.
>>
>
> If the goal was performance I would agree but my goal is removing
> unnecessary code and getting our thinking back to browser based
> development. An alt impl that does not use the cordova.js ceremonies could
> clock in at 10 LOC. I'm not trying to optimize performance so much as
> leaving the footprint for the userland rather than our framework code that
> effectively is a noop. (The nice side effect of this thinking is that we'd
> gain better perf too.)
>
>  [1] https://issues.apache.org/jira/browse/CB-5622
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message