Return-Path: Delivered-To: apmail-geronimo-dev-archive@www.apache.org Received: (qmail 22331 invoked from network); 30 Jul 2008 16:53:40 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 30 Jul 2008 16:53:40 -0000 Received: (qmail 35705 invoked by uid 500); 30 Jul 2008 16:53:37 -0000 Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org Received: (qmail 35654 invoked by uid 500); 30 Jul 2008 16:53:37 -0000 Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@geronimo.apache.org List-Id: Delivered-To: mailing list dev@geronimo.apache.org Received: (qmail 35643 invoked by uid 99); 30 Jul 2008 16:53:37 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 30 Jul 2008 09:53:37 -0700 X-ASF-Spam-Status: No, hits=2.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of banga.shrey@gmail.com designates 64.233.166.180 as permitted sender) Received: from [64.233.166.180] (HELO py-out-1112.google.com) (64.233.166.180) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 30 Jul 2008 16:52:40 +0000 Received: by py-out-1112.google.com with SMTP id u52so77299pyb.11 for ; Wed, 30 Jul 2008 09:52:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type:references; bh=FvTGBjvdCqadnIWjHflnd4ngTwsg2ItSkaBSiO2tMoc=; b=ksI75qwQAOvph3iHUX3Jwa6UqCdczkMA82DHw8pwo8pyF8Je799PPeWGkZNfyizmPh Lx4GO5J0JO7kDVAdkKyX5L+Xd1spogeUcDm6UbzqeI1ec8FK06QRtEWG0N7znQKlml4k MIE4D0xWHJx8OUe4WMRYud+78J2Divzs1/F9U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:references; b=epQl7v4iN1EjaSHR4vN/mbaT6RMgNcPl2VKgc1VT1t3TH7N+Qws03tVV8JNXTYSK+1 9ceVW+dbBR5GJ3e7XNWfmMasgw0Dam0xVAb4m/v4HaC+HBSpkQFLV1rWlyH/OVpbf4DR BJXUKl4+z1aHf4Wcs0JCc211kLZeqip6vvEjM= Received: by 10.141.75.17 with SMTP id c17mr4528738rvl.212.1217436768291; Wed, 30 Jul 2008 09:52:48 -0700 (PDT) Received: by 10.141.68.2 with HTTP; Wed, 30 Jul 2008 09:52:48 -0700 (PDT) Message-ID: <9dc4201d0807300952l7a21c5c5jbbc72c7e88966a37@mail.gmail.com> Date: Wed, 30 Jul 2008 22:22:48 +0530 From: "Shrey Banga" To: dev@geronimo.apache.org Subject: Re: Reducing the dojo footprint in Geronimo In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_36538_12457108.1217436768289" References: <9dc4201d0806260033o1f73faa0ke91c11e3826944cb@mail.gmail.com> <9dc4201d0806270558v6f8b4a8cn4cbcadc60459369c@mail.gmail.com> <9dc4201d0806270800m71842577k8d351b0f0080fbeb@mail.gmail.com> <54242902-EBFD-4D9E-8D02-9426C6606C9C@gmail.com> <486532A2.4090209@apache.org> <5da94e5a0806300429o759006bem9b1160e37d2a6b50@mail.gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_36538_12457108.1217436768289 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Joseph, I think creating a slim version (like mydojo.js) would be, as I pointed out earlier, useless and also not needed. My proposal was to simply get rid of the dojox components (ie remove the dojox folder). What you suggest is creating one giant preprocessed javascript that has all the dojo, dijit components. For one, this js will be massive and therefore unusable and you would basically subvert the dojo.require process which is similar to import* ing* required components as needed in java. Also, as you said this is a maintenance nightmare. The reason for me to mention the dojo builder which creates a single js was for supporting the webapps which currently use dojox once that is removed from G. For those we could perhaps create a single js with the required components. So here is the updated list of options: 1) Removing Dojo from AG and having users include their own optimized Dojo files for their apps. The downside is that we may be inefficient in aggregating multiple copies of Dojo. 2) Leave Dojo support in AG as is now. We can safely rely on the fact that their will be no duplicate instances of dojo for those who use it, but we must now rely on having that dojo overhead even for users who don't utilize it. 3) Creating a slim version of Dojo essentially by removing the dojox folder and creating custom built js for any components that might still need the dojox functionality. Maintaining these customized scripts might be something that could pose a problem. Finally, we could have a plugin with complete dojo support for applications demanding extra web 2.0 functionality. I would still say that since dojox is considered experimental, developers should be wary of using those features as they are subject to modifications. On Wed, Jul 30, 2008 at 9:39 PM, Joseph Leong wrote: > Kevan, > > I am far from having the complete picture, but my understanding for #3: > According to a post from Donald previously, this link is very good > reference for what process is involved: > http://dojotoolkit.org/book/dojo-book-0-9/part-4-meta-dojo/package-system-and-custom-builds, in creating our slim 'mydojo.js'. > > As for the maintenance, i see the scenarios where every app using dojo will > now need to cross reference with what is available in mydojo.js to see if > the feature they want to use is already included. If not we'll have to > re-generate a new slim version of our 'mydojo.js' with the features added. > Furthermore, when an app becomes obsolete or is removed, we will need to > regenerate a new mydojo.js to remove the unnecessary components. > > On the user level, I also see some inefficiency where if one wants to > deploy a product on AG that uses some dojo subsets which is not in our > generated mydojo.js, they'd have to include their own copy of dojo. > > -Joseph Leong > > > On Wed, Jul 30, 2008 at 10:59 AM, Kevan Miller wrote: > >> >> On Jul 29, 2008, at 3:36 PM, Joseph Leong wrote: >> >> Hi everyone, >> >> So i'm building a little widget piece to run on AG and i've come to the >> point of deciding whether i'm going to incorporate any (if) dojo/dojox >> components into it. I know we've had varying discussions about reducing the >> dojo footprint. To summarize i believe the only thing we've agreed on so >> far is removing the unncessary /tests , but i'm wondering if the community >> had anymore input on keeping dojox around? To summarize it is my >> understanding these are the choices suggested so far: >> >> 1) Removing Dojo from AG and having users include their own optimized Dojo >> files for their apps. The downside is that we may be inefficient in >> aggregating multiple copies of Dojo. >> >> 2) Leave Dojo support in AG as is now. We can safely rely on the fact that >> their will be no duplicate instances of dojo for those who use it, but we >> must now rely on having that dojo overhead even for users who don't utilize >> it. >> >> 3) Creating a slim version of Dojo to support the features relying on it >> in AG, thus allowing users who want to demonstrate fundamental dojo features >> to utilize it - but however we incur the maintenance overhead of creating >> new builds of Dojo to incorporate with AG releases as new fundamental AG >> components with Dojo are included. >> >> Personally, I feel the functionality subset of DojoX captures a lot of >> what this Web2.0 era is looking for. Although it may make more sense to go >> with option 3, now, i feel it's only a matter of time before we switch over >> to option 2. To provide the community with a better grasp of what the DojoX >> functionalities are goto: http://dojocampus.org/explorer/#Dojox and >> you'll find yourself quite surprised at how innovative and integrated these >> technologies are influencing your favorite sites. >> >> >> Thanks a lot for picking this up, again, Joseph. >> >> Personally, I'd like to see the Dojo footprint within Geronimo reduced. >> It's pretty simple to make a full-Dojo plugin that users can install, if >> they want a full Dojo library available. IMO, this can meet the needs of >> Dojo users (as described in #2). >> >> Can you help me understand the maintenance overhead of creating a >> customized Dojo library? If #3 is high maintenance, I may need to >> reconsider. >> >> --kevan >> >> > -- Shrey Banga Bachelor of Technology, III year Department of Electrical Engineering Indian Institute of Technology Roorkee ------=_Part_36538_12457108.1217436768289 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Joseph,

I think creating a slim version (like mydojo.js) would be, as I pointed out earlier, useless and also not needed. My proposal was to simply get rid of the dojox components (ie remove the dojox folder). What you suggest is creating one giant preprocessed javascript that has all the dojo, dijit components. For one, this js will be massive and therefore unusable and you would basically subvert the dojo.require process which is similar to importing required components as needed in java. Also, as you said this is a maintenance nightmare.
The reason for me to mention the dojo builder which creates a single js was for supporting the webapps which currently use dojox once that is removed from G. For those we could perhaps create a single js with the required components.
So here is the updated list of options:
1) Removing Dojo from AG and having users include their own optimized Dojo files for their apps. The downside is that we may be inefficient in aggregating multiple copies of Dojo.

2) Leave Dojo support in AG as is now. We can safely rely on the fact that their will be no duplicate instances of dojo for those who use it, but we must now rely on having that dojo overhead even for users who don't utilize it.

3) Creating a slim version of Dojo essentially by removing the dojox folder and creating custom built js for any components that might still need the dojox functionality. Maintaining these customized scripts might be something that could pose a problem. Finally, we could have a plugin with complete dojo support for applications demanding extra web 2.0 functionality.

I would still say that since dojox is considered experimental, developers should be wary of using those features as they are subject to modifications.

On Wed, Jul 30, 2008 at 9:39 PM, Joseph Leong <josephcleong@gmail.com> wrote:
Kevan,

I am far from having the complete picture, but my understanding for #3:
According to a post from Donald previously, this link is very good reference for what process is involved: http://dojotoolkit.org/book/dojo-book-0-9/part-4-meta-dojo/package-system-and-custom-builds , in creating our slim  'mydojo.js'.

As for the maintenance, i see the scenarios where every app using dojo will now need to cross reference with what is available in mydojo.js to see if the feature they want to use is already included.  If not we'll have to re-generate a new slim version of our 'mydojo.js' with the features added.  Furthermore, when an app becomes obsolete or is removed, we will need to regenerate a new mydojo.js to remove the unnecessary components. 

On the user level, I also see some inefficiency where if one wants to deploy a product on AG that uses some dojo subsets which is not in our generated mydojo.js, they'd have to include their own copy of dojo.

-Joseph Leong


On Wed, Jul 30, 2008 at 10:59 AM, Kevan Miller <kevan.miller@gmail.com> wrote:

On Jul 29, 2008, at 3:36 PM, Joseph Leong wrote:

Hi everyone,

So i'm building a little widget piece to run on AG and i've come to the point of deciding whether i'm going to incorporate any (if) dojo/dojox components into it.  I know we've had varying discussions about reducing the dojo footprint.  To summarize i believe the only thing we've agreed on so far is removing the unncessary /tests , but i'm wondering if the community had anymore input on keeping dojox around?  To summarize it is my understanding these are the choices suggested so far:

1) Removing Dojo from AG and having users include their own optimized Dojo files for their apps. The downside is that we may be inefficient in aggregating multiple copies of Dojo.

2) Leave Dojo support in AG as is now. We can safely rely on the fact that their will be no duplicate instances of dojo for those who use it, but we must now rely on having that dojo overhead even for users who don't utilize it.

3) Creating a slim version of Dojo to support the features relying on it in AG, thus allowing users who want to demonstrate fundamental dojo features to utilize it - but however we incur the maintenance overhead of creating new builds of Dojo to incorporate with AG releases as new fundamental AG components with Dojo are included.

Personally, I feel the functionality subset of DojoX captures a lot of what this Web2.0 era is looking for.  Although it may make more sense to go with option 3, now, i feel it's only a matter of time before we switch over to option 2.  To provide the community with a better grasp of what the DojoX functionalities are goto: http://dojocampus.org/explorer/#Dojox and you'll find yourself quite surprised at how innovative and integrated these technologies are influencing your favorite sites.

Thanks a lot for picking this up, again, Joseph.

Personally, I'd like to see the Dojo footprint within Geronimo reduced. It's pretty simple to make a full-Dojo plugin that users can install, if they want a full Dojo library available. IMO, this can meet the needs of Dojo users (as described in #2).

Can you help me understand the maintenance overhead of creating a customized Dojo library? If #3 is high maintenance, I may need to reconsider.

--kevan





--
Shrey Banga
Bachelor of Technology, III year
Department of Electrical Engineering
Indian Institute of Technology Roorkee
------=_Part_36538_12457108.1217436768289--