Return-Path: Delivered-To: apmail-geronimo-dev-archive@www.apache.org Received: (qmail 60922 invoked from network); 27 Jun 2008 14:37:56 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 27 Jun 2008 14:37:56 -0000 Received: (qmail 47372 invoked by uid 500); 27 Jun 2008 14:37:57 -0000 Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org Received: (qmail 47304 invoked by uid 500); 27 Jun 2008 14:37:56 -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 47293 invoked by uid 99); 27 Jun 2008 14:37:56 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 27 Jun 2008 07:37:56 -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 josephcleong@gmail.com designates 74.125.44.28 as permitted sender) Received: from [74.125.44.28] (HELO yx-out-2324.google.com) (74.125.44.28) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 27 Jun 2008 14:37:06 +0000 Received: by yx-out-2324.google.com with SMTP id 3so165926yxj.85 for ; Fri, 27 Jun 2008 07:37:26 -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=4vRb9nSyFo6o6osafzpkIlU45UUkmK1scgEcV4ABTIE=; b=gmE/gJ9ZpLFKc8HBQCYVYSzD1YzgsAk0tsl3795qiDZWOJTd29cFeyXukqo4i54BLZ gv1b6w5zZTYSoFX3AHktvIA55hXgR2FvdIRp0qAZy6PWaM9baNtcGC81XhCafHU3pBct 51uq52ci0eRFnxZeL7H8nsdqPCAsJ6SLJzSU0= 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=wTyhMx6u9KA0FrPbgKoju9MCobaiszPX9MyfKHvQxUNC2q/5v3DCHVwFdtlxvsIJQ9 PPWggt0PhRrfoO7DMoKcD9AU7Ac/98ng8GSdEqOwq910jxw/uUb10DumMWKV9ExlOjcZ 8Nain7LUPkVzomA7BhzLzYgw5iB7ayhxO1loQ= Received: by 10.150.12.3 with SMTP id 3mr2382833ybl.14.1214577445949; Fri, 27 Jun 2008 07:37:25 -0700 (PDT) Received: by 10.150.135.19 with HTTP; Fri, 27 Jun 2008 07:37:25 -0700 (PDT) Message-ID: Date: Fri, 27 Jun 2008 10:37:25 -0400 From: "Joseph Leong" To: dev@geronimo.apache.org Subject: Re: Reducing the dojo footprint in Geronimo In-Reply-To: <9dc4201d0806270558v6f8b4a8cn4cbcadc60459369c@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_7800_29813820.1214577445960" References: <9dc4201d0806260033o1f73faa0ke91c11e3826944cb@mail.gmail.com> <48640099.2070506@apache.org> <9dc4201d0806270009n22e9efc4q7e245264b0916757@mail.gmail.com> <4864DFA7.7080703@apache.org> <9dc4201d0806270558v6f8b4a8cn4cbcadc60459369c@mail.gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_7800_29813820.1214577445960 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I agree with you Jason and I feel 'experimental' can be casted in different light. Looking at it's function exclusively, it seems to be fitting our needs and is stable from what i can see. Having said that, i agree with your approach Shrey - The part where you mentioned the ability to create a custom js for the specific functionality of the monitoring console that required particular dojox dependencies. So that would give us the slimmest version of what we want from DojoX and allow us to remove the rest. As for the including the rest of DojoX, since it a significant part of the reducing effort. Would it make sense to build a custom js for monitoring, remove the rest of DojoX and if the development starts shifting to a real need for DojoX to make a decision to bring it back in the future? As pointed out, a lot of the functionality can be and was intended to be completed with dijit and dojo. Thoughts? -Joseph Leong On Fri, Jun 27, 2008 at 8:58 AM, Shrey Banga wrote: > Donald, > > Are you suggesting we build all of the dojo, dijit and dojox scripts into > one single js and use that? I think that will be highly inexpedient. > For one, running the builder for all possible scripts in dojo is both > extremely tedious as the builder requires that we provide the basic modules > that our webapp needs, similar to dojo.requires in the webpages. In this > case, we'll have to require all the modules to be sure that none are left. > Even if we manage to do that, what we'll get is a massive js that will kill > most, if not all, webapps. What I'm suggesting is to build the specific > modules required by the Monitor application into one js and include that > within the application instead of using the dojo files in the repository. > Then we can get rid of dojox and advise users to do the same. > > > On Fri, Jun 27, 2008 at 6:10 PM, Donald Woods wrote: > >> Then why not keep the dojox and just rebuild everything (minnus the demo >> and test files) into a single .js for the Dojo Plugin? >> >> I really don't want 2 copies of this in the server, which would be worse >> than 1 larger copy.... >> >> >> -Donald >> >> >> Shrey Banga wrote: >> >>> Dojo does have a builder which can parse the dojo tree to create a single >>> .js that is compressed and can be included with the webapp. Although this is >>> intended for the purpose of speeding up webpages and avoiding lock up of >>> resources while all the js is loaded, it can be used similarly for the >>> purpose of the monitor console so that dojox can be removed from the >>> repository and the .js that has been built can be included with the monitor. >>> I think this would be a better approach than manually fishing out the >>> required js. This should be the approach any geronimo user intending to use >>> dojox features should use as they are bound to change in further releases. >>> As Lin Sun pointed out, we shouldn't really be using the experimental >>> features anyway. As and when these features are accommodated in the >>> dojo/dijit components we can include them too. >>> >>> On Fri, Jun 27, 2008 at 2:29 AM, Lin Sun >> linsun.unc@gmail.com>> wrote: >>> >>> Would it be possible that we release the monitor console piece as an >>> external plugin where users can install it on demand? That way, >>> whoever wants to see the monitor console piece can install it along >>> with the dojox dependency and we don't need to figure out/bundle which >>> pieces of dojox we need. Also, I am a bit surprised that we are >>> using dojox as that is supposed to be incubator phase for dojo. >>> >>> Lin >>> >>> >>> >>> >>> -- >>> Shrey Banga >>> Bachelor of Technology, III year >>> Department of Electrical Engineering >>> Indian Institute of Technology Roorkee >>> >> > > > -- > Shrey Banga > Bachelor of Technology, III year > Department of Electrical Engineering > Indian Institute of Technology Roorkee > ------=_Part_7800_29813820.1214577445960 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I agree with you Jason and I feel 'experimental' can be casted in different light.  Looking at it's function exclusively, it seems to be fitting our needs and is stable from what i can see.  Having said that, i agree with your approach Shrey - The part where you mentioned the ability to create a custom js for the specific functionality of the monitoring console that required particular dojox dependencies.  So that would give us the slimmest version of what we want from DojoX and allow us to remove the rest.

As for the including the rest of DojoX, since it a significant part of the reducing effort.  Would it make sense to build a custom js for monitoring, remove the rest of DojoX and if the development starts shifting to a real need for DojoX to make a decision to bring it back in the future? As pointed out, a lot of the functionality can be and was intended to be completed with dijit and dojo. Thoughts?

-Joseph Leong



On Fri, Jun 27, 2008 at 8:58 AM, Shrey Banga <banga.shrey@gmail.com> wrote:
Donald,

Are you suggesting we build all of the dojo, dijit and dojox scripts into one single js and use that? I think that will be highly inexpedient.
For one, running the builder for all possible scripts in dojo is both extremely tedious as the builder requires that we provide the basic modules that our webapp needs, similar to dojo.requires in the webpages. In this case, we'll have to require all the modules to be sure that none are left. Even if we manage to do that, what we'll get is a massive js that will kill most, if not all, webapps. What I'm suggesting is to build the specific modules required by the Monitor application into one js and include that within the application instead of using the dojo files in the repository. Then we can get rid of dojox and advise users to do the same.


On Fri, Jun 27, 2008 at 6:10 PM, Donald Woods <dwoods@apache.org> wrote:
Then why not keep the dojox and just rebuild everything (minnus the demo and test files) into a single .js for the Dojo Plugin?

I really don't want 2 copies of this in the server, which would be worse than 1 larger copy....


-Donald


Shrey Banga wrote:
Dojo does have a builder which can parse the dojo tree to create a single .js that is compressed and can be included with the webapp. Although this is intended for the purpose of speeding up webpages and avoiding lock up of resources while all the js is loaded, it can be used similarly for the purpose of the monitor console so that dojox can be removed from the repository and the .js that has been built can be included with the monitor. I think this would be a better approach than manually fishing out the required js. This should be the approach any geronimo user intending to use dojox features should use as they are bound to change in further releases.
As Lin Sun pointed out, we shouldn't really be using the experimental features anyway. As and when these features are accommodated in the dojo/dijit components we can include them too.

On Fri, Jun 27, 2008 at 2:29 AM, Lin Sun <linsun.unc@gmail.com <mailto:linsun.unc@gmail.com>> wrote:

   Would it be possible that we release the monitor console piece as an
   external plugin where users can install it on demand?  That way,
   whoever wants to see the monitor console piece can install it along
   with the dojox dependency and we don't need to figure out/bundle which
   pieces of dojox we need.    Also, I am a bit surprised that we are
   using dojox as that is supposed to be incubator phase for dojo.

   Lin




--
Shrey Banga
Bachelor of Technology, III year
Department of Electrical Engineering
Indian Institute of Technology Roorkee



--
Shrey Banga
Bachelor of Technology, III year
Department of Electrical Engineering
Indian Institute of Technology Roorkee

------=_Part_7800_29813820.1214577445960--