I may be misunderstanding what your proposing, Donald, but I'm not sure if this suggestion would actually decrease the dojo footprint at all. From my understanding, the monitoring plugin that is included in the EE servers requires a dojox feature (charting). This would mean that the monitoring plugin would pull the dojo-full plugin into the EE server resulting in no actual decrease in dojo footprint. This idea would be nifty for custom server images, but my understanding was that this discussion was in relation to the EE distributions. I still like the idea, I'm just not sure it's going to accomplish what Shrey was suggesting. I'm inclined to side with Donald's idea, even though I don't think it will decrease the EE server's dojo footprint. It provides users who are building custom assemblies the option to include dojo easily in their server without worrying about dojox components they might have no intention of using.
On Mon, Aug 4, 2008 at 10:59 AM, Donald Woods <[EMAIL PROTECTED]> wrote: > 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 <[EMAIL PROTECTED]<mailto: >> [EMAIL PROTECTED]>> wrote: >> >> >> >> On Sat, Jun 28, 2008 at 12:04 AM, Donald Woods <[EMAIL PROTECTED] >> <mailto:[EMAIL PROTECTED]>> 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 >> >> -- ~Jason Warner
