Re: Reducing the dojo footprint in Geronimo
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
Re: Reducing the dojo footprint in Geronimo
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
Re: Reducing the dojo footprint in Geronimo
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
Re: Reducing the dojo footprint in Geronimo
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 [EMAIL PROTECTED]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
Re: Reducing the dojo footprint in Geronimo
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 [EMAIL PROTECTED]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 [EMAIL PROTECTED]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
Re: Reducing the dojo footprint in Geronimo
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] wrote: On Sat, Jun 28, 2008 at 12:04 AM, Donald Woods [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
Re: Reducing the dojo footprint in Geronimo
On Sat, Jun 28, 2008 at 12:04 AM, Donald Woods [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
Re: Reducing the dojo footprint in Geronimo
On Fri, Jun 27, 2008 at 9:52 PM, Kevan Miller [EMAIL PROTECTED] 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... Perfect. I am +1. --kevan -- Thanks, Shiva
Re: Reducing the dojo footprint in Geronimo
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 [EMAIL PROTECTED] 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
Re: Reducing the dojo footprint in Geronimo
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 [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] 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 smime.p7s Description: S/MIME Cryptographic Signature
Re: Reducing the dojo footprint in Geronimo
I could be completely wrong on this, as I can't remember any specific examples, but haven't we used incubator projects in geronimo before? I don't see any issue with using dojox if it's the best fit for our needs and the code is stable, which I believe it has proven itself to be. On Thu, Jun 26, 2008 at 4:59 PM, Lin Sun [EMAIL PROTECTED] 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 -- ~Jason Warner
Re: Reducing the dojo footprint in Geronimo
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] mailto: [EMAIL PROTECTED] 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
Re: Reducing the dojo footprint in Geronimo
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] mailto: [EMAIL PROTECTED] 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
Re: Reducing the dojo footprint in Geronimo
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. On Fri, Jun 27, 2008 at 8:07 PM, Joseph Leong [EMAIL PROTECTED] wrote: 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] mailto: [EMAIL PROTECTED] 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 -- Shrey Banga Bachelor of Technology, III year Department of Electrical Engineering Indian Institute of Technology Roorkee
Re: Reducing the dojo footprint in Geronimo
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
Re: Reducing the dojo footprint in Geronimo
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) -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 smime.p7s Description: S/MIME Cryptographic Signature
Re: Reducing the dojo footprint in Geronimo
I have thought about this a lot (since I have become very accustomed to having Dojo 'just be there'). And the consensus (or at least what appears to be becoming the consensus) of only including what is needed for the admin console is probably the best idea. Especially since the installed size of Dojo has ballooned from around 6Meg to around 22Meg. Along with this, we should probably also drop the 'dojo-legacy' plugin (as soon as the work to upgrade to using the 1.1.x version of Dojo is completed). And we should provide a plugin for the full Dojo install. It is easy enough to provide and will help those who have gotten used to having Dojo 'just be there' - upgrade with a minimum of pain. Jay 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) -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
Reducing the dojo footprint in Geronimo
Hi all, I've been working on the EAR PlanCreator and I've observed that dojo is shipped with all the demos, tests and experimental widgets in place, causing the folder to be about 12.8 MB on the expanded server (2.2-SNAPSHOT). Looking at the various folders, I think we can achieve significant reduction in the dojo footprint and eventually of the server itself by removing the following components: dojo/tests - 579 KB dijit/tests - 551 KB dijit/demos - 909 KB dojox - 6.82 MB From a geronimo user's perspective, the tests suite is not of much use as they are meant to test the widgets provided by dojo itself which can be tested by separately downloading the given release instead of shipping it with the server. Similarly, the demos, which are used to exhibit dojo's capabilities, can be run directly from dojo's website or downloaded and run locally without the server. Also, people trying to learn from the demos tend to use the css provided for the purpose of the demo, which is not recommended. My rationale for removing the dojox is that these are marked as experimental by the dojo community and although some components are used often, keeping 6.8 MBs of code that is still experimental does not make sense. It is better to trust the dojo community to shift components from experimental to stable areas and then use them in further releases. Removing the stated components frees up about 8.7 MBs of space on the expanded server, which is huge for a javascript library. Since a Geronimo user can still include these components into his/her webapp we're not really stopping them from using these components, only transferring the overhead of using the lesser used components onto the user. -- Shrey Banga Bachelor of Technology, III year Department of Electrical Engineering Indian Institute of Technology Roorkee
Re: Reducing the dojo footprint in Geronimo
Hi, what you propose makes sense to me. Can you suggest the best way to achieve this, possibly in a JIRA with a patch? Thanks, Lin On 6/26/08, Shrey Banga [EMAIL PROTECTED] wrote: Hi all, I've been working on the EAR PlanCreator and I've observed that dojo is shipped with all the demos, tests and experimental widgets in place, causing the folder to be about 12.8 MB on the expanded server (2.2-SNAPSHOT). Looking at the various folders, I think we can achieve significant reduction in the dojo footprint and eventually of the server itself by removing the following components: dojo/tests - 579 KB dijit/tests - 551 KB dijit/demos - 909 KB dojox - 6.82 MB From a geronimo user's perspective, the tests suite is not of much use as they are meant to test the widgets provided by dojo itself which can be tested by separately downloading the given release instead of shipping it with the server. Similarly, the demos, which are used to exhibit dojo's capabilities, can be run directly from dojo's website or downloaded and run locally without the server. Also, people trying to learn from the demos tend to use the css provided for the purpose of the demo, which is not recommended. My rationale for removing the dojox is that these are marked as experimental by the dojo community and although some components are used often, keeping 6.8 MBs of code that is still experimental does not make sense. It is better to trust the dojo community to shift components from experimental to stable areas and then use them in further releases. Removing the stated components frees up about 8.7 MBs of space on the expanded server, which is huge for a javascript library. Since a Geronimo user can still include these components into his/her webapp we're not really stopping them from using these components, only transferring the overhead of using the lesser used components onto the user. -- Shrey Banga Bachelor of Technology, III year Department of Electrical Engineering Indian Institute of Technology Roorkee
Re: Reducing the dojo footprint in Geronimo
Hi Shrey, I think that makes a lot of sense, especially with the tests and demos. My only comment is i believe the monitoring plugin may use some of the DojoX charting features. However, after doing some research with dojo and AG regarding the 0.4-1.1.1 conversion i think that was the only plugin with dojox issues. Other than that, great idea on reducing the dojo footprint. -Joseph Leong On Thu, Jun 26, 2008 at 12:49 PM, Lin Sun [EMAIL PROTECTED] wrote: Hi, what you propose makes sense to me. Can you suggest the best way to achieve this, possibly in a JIRA with a patch? Thanks, Lin On 6/26/08, Shrey Banga [EMAIL PROTECTED] wrote: Hi all, I've been working on the EAR PlanCreator and I've observed that dojo is shipped with all the demos, tests and experimental widgets in place, causing the folder to be about 12.8 MB on the expanded server (2.2-SNAPSHOT). Looking at the various folders, I think we can achieve significant reduction in the dojo footprint and eventually of the server itself by removing the following components: dojo/tests - 579 KB dijit/tests - 551 KB dijit/demos - 909 KB dojox - 6.82 MB From a geronimo user's perspective, the tests suite is not of much use as they are meant to test the widgets provided by dojo itself which can be tested by separately downloading the given release instead of shipping it with the server. Similarly, the demos, which are used to exhibit dojo's capabilities, can be run directly from dojo's website or downloaded and run locally without the server. Also, people trying to learn from the demos tend to use the css provided for the purpose of the demo, which is not recommended. My rationale for removing the dojox is that these are marked as experimental by the dojo community and although some components are used often, keeping 6.8 MBs of code that is still experimental does not make sense. It is better to trust the dojo community to shift components from experimental to stable areas and then use them in further releases. Removing the stated components frees up about 8.7 MBs of space on the expanded server, which is huge for a javascript library. Since a Geronimo user can still include these components into his/her webapp we're not really stopping them from using these components, only transferring the overhead of using the lesser used components onto the user. -- Shrey Banga Bachelor of Technology, III year Department of Electrical Engineering Indian Institute of Technology Roorkee
Re: Reducing the dojo footprint in Geronimo
I think that's a great idea! The more we can reduce the image size the better off we'll be (esp. since these items seems extraneous to what we need). Joe Shrey Banga wrote: Hi all, I've been working on the EAR PlanCreator and I've observed that dojo is shipped with all the demos, tests and experimental widgets in place, causing the folder to be about 12.8 MB on the expanded server (2.2-SNAPSHOT). Looking at the various folders, I think we can achieve significant reduction in the dojo footprint and eventually of the server itself by removing the following components: dojo/tests - 579 KB dijit/tests - 551 KB dijit/demos - 909 KB dojox - 6.82 MB From a geronimo user's perspective, the tests suite is not of much use as they are meant to test the widgets provided by dojo itself which can be tested by separately downloading the given release instead of shipping it with the server. Similarly, the demos, which are used to exhibit dojo's capabilities, can be run directly from dojo's website or downloaded and run locally without the server. Also, people trying to learn from the demos tend to use the css provided for the purpose of the demo, which is not recommended. My rationale for removing the dojox is that these are marked as experimental by the dojo community and although some components are used often, keeping 6.8 MBs of code that is still experimental does not make sense. It is better to trust the dojo community to shift components from experimental to stable areas and then use them in further releases. Removing the stated components frees up about 8.7 MBs of space on the expanded server, which is huge for a javascript library. Since a Geronimo user can still include these components into his/her webapp we're not really stopping them from using these components, only transferring the overhead of using the lesser used components onto the user. -- Shrey Banga Bachelor of Technology, III year Department of Electrical Engineering Indian Institute of Technology Roorkee
Re: Reducing the dojo footprint in Geronimo
Joe, Is it possible to pull in just the dojox charting features? I think the main driving factor of this is to drop dojox as that is 80% of the weight that would be dropped. If we can't keep just the charting features, then we're going to have to keep all of dojox or change how the monitoring plugin draws the graphs (I assume that's what it's used for). On Thu, Jun 26, 2008 at 2:33 PM, Joseph Leong [EMAIL PROTECTED] wrote: Hi Shrey, I think that makes a lot of sense, especially with the tests and demos. My only comment is i believe the monitoring plugin may use some of the DojoX charting features. However, after doing some research with dojo and AG regarding the 0.4-1.1.1 conversion i think that was the only plugin with dojox issues. Other than that, great idea on reducing the dojo footprint. -Joseph Leong On Thu, Jun 26, 2008 at 12:49 PM, Lin Sun [EMAIL PROTECTED] wrote: Hi, what you propose makes sense to me. Can you suggest the best way to achieve this, possibly in a JIRA with a patch? Thanks, Lin On 6/26/08, Shrey Banga [EMAIL PROTECTED] wrote: Hi all, I've been working on the EAR PlanCreator and I've observed that dojo is shipped with all the demos, tests and experimental widgets in place, causing the folder to be about 12.8 MB on the expanded server (2.2-SNAPSHOT). Looking at the various folders, I think we can achieve significant reduction in the dojo footprint and eventually of the server itself by removing the following components: dojo/tests - 579 KB dijit/tests - 551 KB dijit/demos - 909 KB dojox - 6.82 MB From a geronimo user's perspective, the tests suite is not of much use as they are meant to test the widgets provided by dojo itself which can be tested by separately downloading the given release instead of shipping it with the server. Similarly, the demos, which are used to exhibit dojo's capabilities, can be run directly from dojo's website or downloaded and run locally without the server. Also, people trying to learn from the demos tend to use the css provided for the purpose of the demo, which is not recommended. My rationale for removing the dojox is that these are marked as experimental by the dojo community and although some components are used often, keeping 6.8 MBs of code that is still experimental does not make sense. It is better to trust the dojo community to shift components from experimental to stable areas and then use them in further releases. Removing the stated components frees up about 8.7 MBs of space on the expanded server, which is huge for a javascript library. Since a Geronimo user can still include these components into his/her webapp we're not really stopping them from using these components, only transferring the overhead of using the lesser used components onto the user. -- Shrey Banga Bachelor of Technology, III year Department of Electrical Engineering Indian Institute of Technology Roorkee -- ~Jason Warner
Re: Reducing the dojo footprint in Geronimo
Jason, I agree with that approach. The widget and other components are the mainstream features. In efforts to reducing the size and to support the monitoring features , i don't see why not just leave the charting features. Does anyone else see a problem with this? -Joseph Leong On Thu, Jun 26, 2008 at 3:09 PM, Jason Warner [EMAIL PROTECTED] wrote: Joe, Is it possible to pull in just the dojox charting features? I think the main driving factor of this is to drop dojox as that is 80% of the weight that would be dropped. If we can't keep just the charting features, then we're going to have to keep all of dojox or change how the monitoring plugin draws the graphs (I assume that's what it's used for). On Thu, Jun 26, 2008 at 2:33 PM, Joseph Leong [EMAIL PROTECTED] wrote: Hi Shrey, I think that makes a lot of sense, especially with the tests and demos. My only comment is i believe the monitoring plugin may use some of the DojoX charting features. However, after doing some research with dojo and AG regarding the 0.4-1.1.1 conversion i think that was the only plugin with dojox issues. Other than that, great idea on reducing the dojo footprint. -Joseph Leong On Thu, Jun 26, 2008 at 12:49 PM, Lin Sun [EMAIL PROTECTED] wrote: Hi, what you propose makes sense to me. Can you suggest the best way to achieve this, possibly in a JIRA with a patch? Thanks, Lin On 6/26/08, Shrey Banga [EMAIL PROTECTED] wrote: Hi all, I've been working on the EAR PlanCreator and I've observed that dojo is shipped with all the demos, tests and experimental widgets in place, causing the folder to be about 12.8 MB on the expanded server (2.2-SNAPSHOT). Looking at the various folders, I think we can achieve significant reduction in the dojo footprint and eventually of the server itself by removing the following components: dojo/tests - 579 KB dijit/tests - 551 KB dijit/demos - 909 KB dojox - 6.82 MB From a geronimo user's perspective, the tests suite is not of much use as they are meant to test the widgets provided by dojo itself which can be tested by separately downloading the given release instead of shipping it with the server. Similarly, the demos, which are used to exhibit dojo's capabilities, can be run directly from dojo's website or downloaded and run locally without the server. Also, people trying to learn from the demos tend to use the css provided for the purpose of the demo, which is not recommended. My rationale for removing the dojox is that these are marked as experimental by the dojo community and although some components are used often, keeping 6.8 MBs of code that is still experimental does not make sense. It is better to trust the dojo community to shift components from experimental to stable areas and then use them in further releases. Removing the stated components frees up about 8.7 MBs of space on the expanded server, which is huge for a javascript library. Since a Geronimo user can still include these components into his/her webapp we're not really stopping them from using these components, only transferring the overhead of using the lesser used components onto the user. -- Shrey Banga Bachelor of Technology, III year Department of Electrical Engineering Indian Institute of Technology Roorkee -- ~Jason Warner
Re: Reducing the dojo footprint in Geronimo
Actually thinking about this further, i'm not so sure stripping out DojoX would be a good idea. DojoX has a lot features, and i realize we aren't using them now. But thinking about it the process of stripping down DojoX to just the components in Monitoring might be a maintenance nightmare. Taking a deeper look, there are a lot of dependencies and trails that you have to follow in the js files to completely separate out functioning pieces of dojox. In addition, if anyone were to add a another dojox feature, we'd have to follow suite with stripping out that component exclusively to achieve a small package size. Thoughts? -Joseph Leong On Thu, Jun 26, 2008 at 3:18 PM, Joseph Leong [EMAIL PROTECTED] wrote: Jason, I agree with that approach. The widget and other components are the mainstream features. In efforts to reducing the size and to support the monitoring features , i don't see why not just leave the charting features. Does anyone else see a problem with this? -Joseph Leong On Thu, Jun 26, 2008 at 3:09 PM, Jason Warner [EMAIL PROTECTED] wrote: Joe, Is it possible to pull in just the dojox charting features? I think the main driving factor of this is to drop dojox as that is 80% of the weight that would be dropped. If we can't keep just the charting features, then we're going to have to keep all of dojox or change how the monitoring plugin draws the graphs (I assume that's what it's used for). On Thu, Jun 26, 2008 at 2:33 PM, Joseph Leong [EMAIL PROTECTED] wrote: Hi Shrey, I think that makes a lot of sense, especially with the tests and demos. My only comment is i believe the monitoring plugin may use some of the DojoX charting features. However, after doing some research with dojo and AG regarding the 0.4-1.1.1 conversion i think that was the only plugin with dojox issues. Other than that, great idea on reducing the dojo footprint. -Joseph Leong On Thu, Jun 26, 2008 at 12:49 PM, Lin Sun [EMAIL PROTECTED] wrote: Hi, what you propose makes sense to me. Can you suggest the best way to achieve this, possibly in a JIRA with a patch? Thanks, Lin On 6/26/08, Shrey Banga [EMAIL PROTECTED] wrote: Hi all, I've been working on the EAR PlanCreator and I've observed that dojo is shipped with all the demos, tests and experimental widgets in place, causing the folder to be about 12.8 MB on the expanded server (2.2-SNAPSHOT). Looking at the various folders, I think we can achieve significant reduction in the dojo footprint and eventually of the server itself by removing the following components: dojo/tests - 579 KB dijit/tests - 551 KB dijit/demos - 909 KB dojox - 6.82 MB From a geronimo user's perspective, the tests suite is not of much use as they are meant to test the widgets provided by dojo itself which can be tested by separately downloading the given release instead of shipping it with the server. Similarly, the demos, which are used to exhibit dojo's capabilities, can be run directly from dojo's website or downloaded and run locally without the server. Also, people trying to learn from the demos tend to use the css provided for the purpose of the demo, which is not recommended. My rationale for removing the dojox is that these are marked as experimental by the dojo community and although some components are used often, keeping 6.8 MBs of code that is still experimental does not make sense. It is better to trust the dojo community to shift components from experimental to stable areas and then use them in further releases. Removing the stated components frees up about 8.7 MBs of space on the expanded server, which is huge for a javascript library. Since a Geronimo user can still include these components into his/her webapp we're not really stopping them from using these components, only transferring the overhead of using the lesser used components onto the user. -- Shrey Banga Bachelor of Technology, III year Department of Electrical Engineering Indian Institute of Technology Roorkee -- ~Jason Warner
Re: Reducing the dojo footprint in Geronimo
Shrey, As previously mentioned by Joe, the monitoring console uses pieces from dojox. This eliminates the possibility of removing the entirety of dojox, however you could break it apart keeping only the pieces required in, which would be mildly challenging, because as I recall there are a number of dependent files included in some of the charting components. Thanks, Erik B. Craig On Thu, Jun 26, 2008 at 3:33 AM, Shrey Banga [EMAIL PROTECTED] wrote: Hi all, I've been working on the EAR PlanCreator and I've observed that dojo is shipped with all the demos, tests and experimental widgets in place, causing the folder to be about 12.8 MB on the expanded server (2.2-SNAPSHOT). Looking at the various folders, I think we can achieve significant reduction in the dojo footprint and eventually of the server itself by removing the following components: dojo/tests - 579 KB dijit/tests - 551 KB dijit/demos - 909 KB dojox - 6.82 MB From a geronimo user's perspective, the tests suite is not of much use as they are meant to test the widgets provided by dojo itself which can be tested by separately downloading the given release instead of shipping it with the server. Similarly, the demos, which are used to exhibit dojo's capabilities, can be run directly from dojo's website or downloaded and run locally without the server. Also, people trying to learn from the demos tend to use the css provided for the purpose of the demo, which is not recommended. My rationale for removing the dojox is that these are marked as experimental by the dojo community and although some components are used often, keeping 6.8 MBs of code that is still experimental does not make sense. It is better to trust the dojo community to shift components from experimental to stable areas and then use them in further releases. Removing the stated components frees up about 8.7 MBs of space on the expanded server, which is huge for a javascript library. Since a Geronimo user can still include these components into his/her webapp we're not really stopping them from using these components, only transferring the overhead of using the lesser used components onto the user. -- Shrey Banga Bachelor of Technology, III year Department of Electrical Engineering Indian Institute of Technology Roorkee
Re: Reducing the dojo footprint in Geronimo
I have a faint recollection of someone saying that dojo had a feature whereby it could come up with a application-specific bundle containing only the dojo stuff used by the app. If so, maybe we could include all of dojo (whatever that means) in the repo but use this customization feature to extract what the console actually uses??? there's at least a 90% chance this doesn't make any sense, so feel free to ignore or point out how/why it doesn't :-) thanks david jencks On Jun 26, 2008, at 12:35 PM, Joseph Leong wrote: Actually thinking about this further, i'm not so sure stripping out DojoX would be a good idea. DojoX has a lot features, and i realize we aren't using them now. But thinking about it the process of stripping down DojoX to just the components in Monitoring might be a maintenance nightmare. Taking a deeper look, there are a lot of dependencies and trails that you have to follow in the js files to completely separate out functioning pieces of dojox. In addition, if anyone were to add a another dojox feature, we'd have to follow suite with stripping out that component exclusively to achieve a small package size. Thoughts? -Joseph Leong On Thu, Jun 26, 2008 at 3:18 PM, Joseph Leong [EMAIL PROTECTED] wrote: Jason, I agree with that approach. The widget and other components are the mainstream features. In efforts to reducing the size and to support the monitoring features , i don't see why not just leave the charting features. Does anyone else see a problem with this? -Joseph Leong On Thu, Jun 26, 2008 at 3:09 PM, Jason Warner [EMAIL PROTECTED] wrote: Joe, Is it possible to pull in just the dojox charting features? I think the main driving factor of this is to drop dojox as that is 80% of the weight that would be dropped. If we can't keep just the charting features, then we're going to have to keep all of dojox or change how the monitoring plugin draws the graphs (I assume that's what it's used for). On Thu, Jun 26, 2008 at 2:33 PM, Joseph Leong [EMAIL PROTECTED] wrote: Hi Shrey, I think that makes a lot of sense, especially with the tests and demos. My only comment is i believe the monitoring plugin may use some of the DojoX charting features. However, after doing some research with dojo and AG regarding the 0.4-1.1.1 conversion i think that was the only plugin with dojox issues. Other than that, great idea on reducing the dojo footprint. -Joseph Leong On Thu, Jun 26, 2008 at 12:49 PM, Lin Sun [EMAIL PROTECTED] wrote: Hi, what you propose makes sense to me. Can you suggest the best way to achieve this, possibly in a JIRA with a patch? Thanks, Lin On 6/26/08, Shrey Banga [EMAIL PROTECTED] wrote: Hi all, I've been working on the EAR PlanCreator and I've observed that dojo is shipped with all the demos, tests and experimental widgets in place, causing the folder to be about 12.8 MB on the expanded server (2.2- SNAPSHOT). Looking at the various folders, I think we can achieve significant reduction in the dojo footprint and eventually of the server itself by removing the following components: dojo/tests - 579 KB dijit/tests - 551 KB dijit/demos - 909 KB dojox - 6.82 MB From a geronimo user's perspective, the tests suite is not of much use as they are meant to test the widgets provided by dojo itself which can be tested by separately downloading the given release instead of shipping it with the server. Similarly, the demos, which are used to exhibit dojo's capabilities, can be run directly from dojo's website or downloaded and run locally without the server. Also, people trying to learn from the demos tend to use the css provided for the purpose of the demo, which is not recommended. My rationale for removing the dojox is that these are marked as experimental by the dojo community and although some components are used often, keeping 6.8 MBs of code that is still experimental does not make sense. It is better to trust the dojo community to shift components from experimental to stable areas and then use them in further releases. Removing the stated components frees up about 8.7 MBs of space on the expanded server, which is huge for a javascript library. Since a Geronimo user can still include these components into his/her webapp we're not really stopping them from using these components, only transferring the overhead of using the lesser used components onto the user. -- Shrey Banga Bachelor of Technology, III year Department of Electrical Engineering Indian Institute of Technology Roorkee -- ~Jason Warner
Re: Reducing the dojo footprint in Geronimo
On Jun 26, 2008, at 3:33 AM, Shrey Banga wrote: Hi all, I've been working on the EAR PlanCreator and I've observed that dojo is shipped with all the demos, tests and experimental widgets in place, causing the folder to be about 12.8 MB on the expanded server (2.2-SNAPSHOT). Looking at the various folders, I think we can achieve significant reduction in the dojo footprint and eventually of the server itself by removing the following components: dojo/tests - 579 KB dijit/tests - 551 KB dijit/demos - 909 KB dojox - 6.82 MB From a geronimo user's perspective, the tests suite is not of much use as they are meant to test the widgets provided by dojo itself which can be tested by separately downloading the given release instead of shipping it with the server. Similarly, the demos, which are used to exhibit dojo's capabilities, can be run directly from dojo's website or downloaded and run locally without the server. Also, people trying to learn from the demos tend to use the css provided for the purpose of the demo, which is not recommended. My rationale for removing the dojox is that these are marked as experimental by the dojo community and although some components are used often, keeping 6.8 MBs of code that is still experimental does not make sense. It is better to trust the dojo community to shift components from experimental to stable areas and then use them in further releases. Removing the stated components frees up about 8.7 MBs of space on the expanded server, which is huge for a javascript library. Since a Geronimo user can still include these components into his/her webapp we're not really stopping them from using these components, only transferring the overhead of using the lesser used components onto the user. Sounds good to me, in principle. Would like to understand the purpose of the dojox library. Recently, while unpacking a geronimo server archive, I was struck by the number of dojo files in the server. Just took a look at a Geronimo 2.1.1 server image: 'find . | grep dojo | wc' shows 2655 dojo related files/directories 'find . | wc' shows 5735 total files/directories. 46% of our files are for dojo... That's crazy... --kevan
Re: Reducing the dojo footprint in Geronimo
Here is the link to creating a custom Dojo package/build - http://dojotoolkit.org/book/dojo-book-0-9/part-4-meta-dojo/package-system-and-custom-builds I would rather include all the dojox components, so we don't have to keep rebuilding as we pickup new releases or add new features to the console or samples... -Donald Shrey Banga wrote: Hi all, I've been working on the EAR PlanCreator and I've observed that dojo is shipped with all the demos, tests and experimental widgets in place, causing the folder to be about 12.8 MB on the expanded server (2.2-SNAPSHOT). Looking at the various folders, I think we can achieve significant reduction in the dojo footprint and eventually of the server itself by removing the following components: dojo/tests - 579 KB dijit/tests - 551 KB dijit/demos - 909 KB dojox - 6.82 MB From a geronimo user's perspective, the tests suite is not of much use as they are meant to test the widgets provided by dojo itself which can be tested by separately downloading the given release instead of shipping it with the server. Similarly, the demos, which are used to exhibit dojo's capabilities, can be run directly from dojo's website or downloaded and run locally without the server. Also, people trying to learn from the demos tend to use the css provided for the purpose of the demo, which is not recommended. My rationale for removing the dojox is that these are marked as experimental by the dojo community and although some components are used often, keeping 6.8 MBs of code that is still experimental does not make sense. It is better to trust the dojo community to shift components from experimental to stable areas and then use them in further releases. Removing the stated components frees up about 8.7 MBs of space on the expanded server, which is huge for a javascript library. Since a Geronimo user can still include these components into his/her webapp we're not really stopping them from using these components, only transferring the overhead of using the lesser used components onto the user. -- Shrey Banga Bachelor of Technology, III year Department of Electrical Engineering Indian Institute of Technology Roorkee smime.p7s Description: S/MIME Cryptographic Signature
Re: Reducing the dojo footprint in Geronimo
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
