incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Viras <vi...@users.sourceforge.net>
Subject Re: Unified phonegap javascript layer incorperating modules / plugins
Date Sun, 27 Nov 2011 07:08:14 GMT
I didn't say it doesn't make sense (in fact, as you pointed out, it
makes a lot of sense in some cases). I just wanted to point out that it
might not be allowed.

Loading external execution code is explicitly not allowed by Apples App
Guidelines. That's all I wanted to note!

Am 25.11.2011 16:37, schrieb Brian LeRoux:
> 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
>>
> 


-- 
GOFG - Get On Fat Guy
http://www.gofg.at/ - powered by PhoneGap

Mime
View raw message