geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Joseph Leong" <josephcle...@gmail.com>
Subject Re: Reducing the dojo footprint in Geronimo
Date Wed, 30 Jul 2008 16:09:31 GMT
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 <kevan.miller@gmail.com>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
>
>

Mime
View raw message