Re: Reducing the dojo footprint in Geronimo

[Jason Warner]

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]> [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 p

Re: Reducing the dojo footprint in Geronimo

[Donald Woods]

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] 
> 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 requ

Re: Reducing the dojo footprint in Geronimo

[Shrey Banga]

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 plu

Re: Reducing the dojo footprint in Geronimo

[Joseph Leong]

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

[Kevan Miller]

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 Leong]

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

[Shiva Kumar H R]

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

[Shiva Kumar H R]

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

[Jay D. McHugh]

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

Re: Reducing the dojo footprint in Geronimo

[Donald Woods]

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

[Kevan Miller]

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

[Shrey Banga]

> 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] >>> [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

[Joseph Leong]

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] >> [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

[Shrey Banga]

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] > [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

[Jason Warner]

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 Woods]

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] 
> 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

[Shrey Banga]

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

[Lin Sun]

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

Re: Reducing the dojo footprint in Geronimo

[Donald Woods]

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

[Kevan Miller]

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

[David Jencks]

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

[Erik B. Craig]

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

[Joseph Leong]

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

[Joseph Leong]

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

[Jason Warner]

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

[Joe Bohn]

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

[Joseph Leong]

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

[Lin Sun]

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

Reducing the dojo footprint in Geronimo

[Shrey Banga]

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