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 <[email protected]> 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: [email protected] - > - Mobile: 646-460-7066 - > ------------------------------------------------ > "Ha ha ha... He doesn't know how to use the three seashells!" - Erwin > > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Brian LeRoux > Sent: Sunday, November 20, 2011 3:25 PM > To: [email protected] > 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 <[email protected]> wrote: >> On Sat, Nov 19, 2011 at 14:21, Andrew Lunny <[email protected]> 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. >
