geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Joseph Leong" <>
Subject Re: Reducing the dojo footprint in Geronimo
Date Tue, 29 Jul 2008 19:36:20 GMT
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

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: and you'll
find yourself quite surprised at how innovative and integrated these
technologies are influencing your favorite sites.

-Joseph Leong

On Mon, Jun 30, 2008 at 7:29 AM, Shiva Kumar H R <> wrote:

> On Sat, Jun 28, 2008 at 12:04 AM, Donald Woods <> 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 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

View raw message