geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donald Woods <dwo...@apache.org>
Subject Re: Reducing the dojo footprint in Geronimo
Date Mon, 04 Aug 2008 14:59:03 GMT
What about a combination of #2 and #3 -
We create a dojo-minimal (no dojox support) and dojo-full plugin under 
geronimo/plugins and only the console modules that need it pull in the 
dojo-minimal, while user apps or samples can pull in dojo-full if 
needed.....


-Donald


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,
> -Joseph Leong
> 
> On Mon, Jun 30, 2008 at 7:29 AM, Shiva Kumar H R <shivahr@gmail.com 
> <mailto:shivahr@gmail.com>> wrote:
> 
> 
> 
>     On Sat, Jun 28, 2008 at 12:04 AM, Donald Woods <dwoods@apache.org
>     <mailto:dwoods@apache.org>> wrote:
> 
>         Sounds like the right solution, given that would allow our
>         console to upgrade at a slower pace and would allow users to
>         choose their own level...
> 
>         Other option, is to drop the /dojo webapp in 2.2, only ship what
>         we need in the console and let users package the Dojo level and
>         features they need within their own apps (which is more portable
>         across different servers anyway....)
> 
> 
>     On http://cwiki.apache.org/GMOxDEV/using-dojo-in-geronimo.html we say:
> 
>     "AJAX developers usually incorporate the Dojo library into their
>     applications by making a copy of its static files (javascript, css,
>     gifs, etc) in their webapp and referencing those files from their
>     servlets and JSPs. The downside of this approach is that each
>     application has a separate copy of the AJAX library, increasing the
>     server's overall footprint and preventing browsers from using a
>     single copy of the library files from their caches. Another downside
>     is that the AJAX library can't be upgraded or otherwise managed
>     independently from the web applications that contain it. For
>     example, a web application deployed across a cluster might need to
>     serve up the static Dojo files from a central location. Hosting the
>     Dojo files in a separate webapp can help work around these problems."
> 
>     So asking users to package the Dojo level and features they need
>     within their own apps would imply the downsides mentioned above.
>     Providing an installable dojo plugin that's equivalent to the /dojo
>     support we currently provide as suggested by Kevan seems to be an
>     excellent alternative.
> 
>         -Donald
> 
> 
> 
>         Kevan Miller wrote:
> 
> 
>             On Jun 27, 2008, at 11:00 AM, Shrey Banga wrote:
> 
> 
>                 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?
> 
>                 I think that makes perfect sense- not only will this do
>                 the part in reducing the dojo footprint, it'll also be
>                 useful as an example to how dojo should be used
>                 optimally in deployment. Another desirable side-effect
>                 would be reduced load times in the monitoring
>                 application, although currently that is not an issue.
> 
> 
>             I'm starting to think that our server should deliver dojo
>             support that is targeted to the requirements of the admin
>             console.
> 
>             For general dojo support, we could provide an installable
>             dojo plugin that's equivalent to the /dojo support we
>             currently provide...
> 
>             --kevan
> 
> 
> 
> 
>     -- 
>     Thanks,
>     Shiva 
> 
> 

Mime
View raw message