geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shiva Kumar H R" <shiv...@gmail.com>
Subject Re: Reducing the dojo footprint in Geronimo
Date Mon, 30 Jun 2008 11:29:15 GMT
On Sat, Jun 28, 2008 at 12:04 AM, Donald Woods <dwoods@apache.org> wrote:

> Sounds like the right solution, given that would allow our console to
> upgrade at a slower pace and would allow users to choose their own level...
>
> Other option, is to drop the /dojo webapp in 2.2, only ship what we need in
> the console and let users package the Dojo level and features they need
> within their own apps (which is more portable across different servers
> anyway....)
>

On http://cwiki.apache.org/GMOxDEV/using-dojo-in-geronimo.html we say:

"AJAX developers usually incorporate the Dojo library into their
applications by making a copy of its static files (javascript, css, gifs,
etc) in their webapp and referencing those files from their servlets and
JSPs. The downside of this approach is that each application has a separate
copy of the AJAX library, increasing the server's overall footprint and
preventing browsers from using a single copy of the library files from their
caches. Another downside is that the AJAX library can't be upgraded or
otherwise managed independently from the web applications that contain it.
For example, a web application deployed across a cluster might need to serve
up the static Dojo files from a central location. Hosting the Dojo files in
a separate webapp can help work around these problems."

So asking users to package the Dojo level and features they need within
their own apps would imply the downsides mentioned above. Providing an
installable dojo plugin that's equivalent to the /dojo support we currently
provide as suggested by Kevan seems to be an excellent alternative.

-Donald
>
>
>
> Kevan Miller wrote:
>
>>
>> On Jun 27, 2008, at 11:00 AM, Shrey Banga wrote:
>>
>>
>>> As for the including the rest of DojoX, since it a significant part of
>>> the reducing effort.  Would it make sense to build a custom js for
>>> monitoring, remove the rest of DojoX and if the development starts shifting
>>> to a real need for DojoX to make a decision to bring it back in the future?
>>>
>>> I think that makes perfect sense- not only will this do the part in
>>> reducing the dojo footprint, it'll also be useful as an example to how dojo
>>> should be used optimally in deployment. Another desirable side-effect would
>>> be reduced load times in the monitoring application, although currently that
>>> is not an issue.
>>>
>>
>> I'm starting to think that our server should deliver dojo support that is
>> targeted to the requirements of the admin console.
>>
>> For general dojo support, we could provide an installable dojo plugin
>> that's equivalent to the /dojo support we currently provide...
>>
>> --kevan
>>
>>


-- 
Thanks,
Shiva

Mime
View raw message