incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian LeRoux...@brian.io>
Subject Re: Unified phonegap javascript layer incorperating modules / plugins
Date Fri, 25 Nov 2011 15:37:22 GMT
Actually, async resource loading has lots of use cases even in a
compiled app. Best one to illustrate would be an app that includes
Google Maps but that isn't the primary function. No sense in loading
it up front but if the user requests that view then loading those JS
assets on demand makes sense --- and having an async mechanism to do
it does too.


On Thu, Nov 24, 2011 at 10:56 PM, Viras <viras@users.sourceforge.net> wrote:
> Just as a side note: async loading of externally libraries shouldn't be
> a top target, especially as this is for example not allowed on iOS and I
> guess it isn't on other platforms as well.
>
> PhoneGap/Callback/Cordova is mainly targeting embedded devices in a
> closed execution environment - this is not a webpage per se. I would
> just like to keep that in mind when doing design decisions.
> (that's just my opinion, please correct me if I'm wrong with that).
>
> Best,
> Wolfgang
>
> Am 24.11.2011 19:46, schrieb Filip Maj:
>> Bit late but better than never...
>>
>> PhoneGap doesn't *need* modules but it *should* have them.
>>
>> +1 for AMD from me.
>>
>> As Laurent said, we need to consider the end-user. Overhead would be.
>> Compilation step is nice for phonegap.js but you cannot expect all scripts
>> will be prepackaged. Consider the case where a PG app async loads
>> libraries externally. AMD should be supported.
>>
>> Another argument in this thread was readability (see Gord's prototype for
>> the readability; Brian you agree too that Gord's demo was pretty). Don't
>> buy that commonJS is "nicer" than AMD - agree with Andrew that that is a
>> question of style. Personally I think AMD is nicer.
>>
>>
>> On 11-11-20 7:19 PM, "Laurent Hasson" <lhasson@rim.com> wrote:
>>
>>> Not about advocacy? I still do innerHTML and table layouts! :) It's about
>>> how to structure the project moving forwards... and I always took this
>>> conversation to be about (1) how to we write the framework, and (2) how
>>> do developers use it.
>>>        - Are we expecting third-party modules to be developed in the
>>> wild?
>>>        - If I write an app and need (a), (b) and (c), but not (d), (e),
>>> and (f), how do I specify that? A build system is how it's done and
>>> having modules clearly defined and dependencies managed helps doing that.
>>>
>>> In WebWorks,  and Tim can correct me, there are potentially hundreds of
>>> modules. To just say it's all one big file with everything in it is
>>> something I don't understand. The fact that it's all packaged and we
>>> don't incur bandwidth and requests to pull it all in doesn't mean it
>>> doesn't take time to load in the browser, parse and so on. Putting it all
>>> on the shoulders of a developer to  bring it all in themselves is also
>>> problematic.
>>>
>>> Maybe I am missing something here, but the way I read your messages is:
>>> phonegap.js is fine as it is, and we don't use any modules, so why start
>>> now? If we believe that we can control it, then maybe that's a fine
>>> position. Otherwise, if it's going to grow, and if third-parties are able
>>> to extend it (i.e., add new modules), and developers are going to find
>>> themselves never needing the entire thing by far, then how do we manage
>>> it?
>>>
>>> And maybe this is not a 1.x thing, maybe we'll re-architect again in 2.0
>>> if the need arises? Advocacy aside, I don't often come across projects
>>> that don't need to end there, or suffer because they did this sooner
>>> rather than later. Just my $.02.
>>>
>>>
>>> Thank you
>>> ------------------------------------------------
>>> - LDH (Laurent Hasson)                         -
>>> - Technical Director, BlackBerry Web Platform  -
>>> - Research In Motion                           -
>>> - Email: lhasson@rim.com                       -
>>> - Mobile: 646-460-7066                         -
>>> ------------------------------------------------
>>> "Ha ha ha... He doesn't know how to use the three seashells!" - Erwin
>>>
>>>
>>> -----Original Message-----
>>> From: brian.leroux@gmail.com [mailto:brian.leroux@gmail.com] On Behalf Of
>>> Brian LeRoux
>>> Sent: Sunday, November 20, 2011 9:22 PM
>>> To: callback-dev@incubator.apache.org
>>> Subject: Re: Unified phonegap javascript layer incorperating modules /
>>> plugins
>>>
>>> With respect Laurent, lets keep the conversation around our project
>>> goals and away from library / pattern advocacy for just the moment. I
>>> don't think we are really debating this correctly (yet) since we
>>> aren't looking at the long view. Ultimately we don't even need a
>>> module system for the single file that is phonegap.js which is in use
>>> today and, indeed, we don't use one or have one. All this discussion
>>> has been framed, I think, around authoring apps with phonegap rather
>>> than how to author phonegap javascript itself.
>>>
>>> The key questions we need to answer to guide this effort:
>>>
>>> Are we looking to enforce a particular module semantics on 3rd party
>>> plugin authors? (Do we have to?) Are plugins all compiled into the
>>> phonegap.js file or are we going to see something like this:
>>>
>>> <script src="phonegap-exec.js"></script>
>>> <script src="phonegap-acceleromter.js"></script>
>>>
>>> ???
>>>
>>> (And leave module loading as an exercise to the end developer...?)
>>>
>>>
>>>
>>> On Sun, Nov 20, 2011 at 5:38 PM, Laurent Hasson <lhasson@rim.com> wrote:
>>>> Things as ambitious as PhoneGap always grow in complexity faster and
>>>> bigger than people think. I have been in way too many projects in the
>>>> past where "anything goes" was the order of the day in terms of macro
>>>> structure, and then it became deeply regretted quickly. I for one don't
>>>> see a downside to using something like AMD. And if we do want to get
>>>> into a much more "micro-kernel" type approach for PhoneGap as a
>>>> platform, then we'll need something.
>>>>
>>>> So I would put the question differently: are people so offended by the
>>>> idea of something AMD-like? What's the downside? Verbosity? Overhead?
>>>> Really? :) It enables tooling, dependency management, code structuring,
>>>> plugins etc... I don't see the downside.
>>>
>>>>
>>>>
>>>> Thank you
>>>> ------------------------------------------------
>>>> - LDH (Laurent Hasson)                         -
>>>> - Technical Director, BlackBerry Web Platform  -
>>>> - Research In Motion                           -
>>>> - Email: lhasson@rim.com                       -
>>>> - Mobile: 646-460-7066                         -
>>>> ------------------------------------------------
>>>> "Ha ha ha... He doesn't know how to use the three seashells!" - Erwin
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: brian.leroux@gmail.com [mailto:brian.leroux@gmail.com] On Behalf
>>>> Of Brian LeRoux
>>>> Sent: Sunday, November 20, 2011 3:25 PM
>>>> To: callback-dev@incubator.apache.org
>>>> Subject: Re: Unified phonegap javascript layer incorperating modules /
>>>> plugins
>>>>
>>>> Would like to draw attention back to the primary goal here: a single
>>>> file phonegap.js that works on all the target platforms:
>>>>
>>>> - ios
>>>> - android
>>>> - blackberry
>>>> - wp7
>>>> - bada
>>>> - qt
>>>> - browser <--- never been an explicit goal, but seems consensus here
>>>> is that it should be given its a common practice during app dev
>>>>
>>>> Right now our module system is classic js: we have no module loader.
>>>> =P We just concat our JS, always have, and leave the loading of that
>>>> file as an exercise for the app developer using phonegap (and it
>>>> should stay that way).
>>>>
>>>> Our secondary goal w/ this effort was to determine how we could move
>>>> code out of the phonegap core and into atomic plugins. With that mind,
>>>> a module system is could make things whole lot nicer.
>>>>
>>>> Do have to use a module system when we 'pluginize'? No.
>>>>
>>>> Here's the big question: *should* authors of plugins be forced into a
>>>> module system? I'm thinking the answer here would be no too ---- but
>>>> I'd love to hear everyones thoughts on that.
>>>>
>>>>
>>>> On Sat, Nov 19, 2011 at 12:42 PM, Patrick Mueller <pmuellr@gmail.com>
>>>> wrote:
>>>>> On Sat, Nov 19, 2011 at 14:21, Andrew Lunny <alunny@gmail.com>
wrote:
>>>>>> For PhoneGap.js, we're dealing with a finite number of modules -
>>>>>> around
>>>>>> twenty I'd guess, plus one for each plugin. Typically, each module
>>>>>> only
>>>>>> depends on phonegap/base - it's very unlikely that, say, the Camera
>>>>>> API
>>>>>> would depend on the Accelerometer, although there may be cases of
>>>>>> cross
>>>>>> dependencies.
>>>>>
>>>>> I take it you aren't including phonegap-plugins in that list (of 20).
>>>>> Shouldn't they be?
>>>>
>>>> ---------------------------------------------------------------------
>>>> This transmission (including any attachments) may contain confidential
>>>> information, privileged material (including material protected by the
>>>> solicitor-client or other applicable privileges), or constitute
>>>> non-public information. Any use of this information by anyone other than
>>>> the intended recipient is prohibited. If you have received this
>>>> transmission in error, please immediately reply to the sender and delete
>>>> this information from your system. Use, dissemination, distribution, or
>>>> reproduction of this transmission by unintended recipients is not
>>>> authorized and may be unlawful.
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> This transmission (including any attachments) may contain confidential
>>> information, privileged material (including material protected by the
>>> solicitor-client or other applicable privileges), or constitute
>>> non-public information. Any use of this information by anyone other than
>>> the intended recipient is prohibited. If you have received this
>>> transmission in error, please immediately reply to the sender and delete
>>> this information from your system. Use, dissemination, distribution, or
>>> reproduction of this transmission by unintended recipients is not
>>> authorized and may be unlawful.
>>
>>
>
> --
> GOFG - Get On Fat Guy
> http://www.gofg.at/ - powered by PhoneGap
>

Mime
View raw message