RE: [Dynapi-Dev] DynAPI build, Splitting files

[Guangyi Wu <gua...@al...>]

The life would be simpler if widgets should not be split. However, when
performance is an considerable issue, we might find later it is also an
admired feature if we can get widgets with an uniformed interface and
browser depended implementation. If we decide to split the API, why don't we
split it in a graceful and general way, so that other modules can also be
benifit?

I would sugest to open a new package to implement this feature after the
current version becomes stable. Only when a class applies this feature, the
correct files/objects would be included. In this way, we do not have to
break the worked version, and get a more generally useful package.

br
George

> 
> Right... widgets should not be split.
> I agree that that's the entire purpose of a core API. The 
> extensions, by
> definition, should be split due to their inherent purpose... 
> extending a
> core object, or a sub class of a core.
> The number of core objects may increase in the future, and 
> that could cause
> the API to grow to a level that is too much for a user to 
> handle.. waiting
> for a download that is...
> 
> ----- Original Message -----
> From: "Scott Andrew LePera" <sc...@sc...>
> To: <dyn...@li...>
> Sent: Wednesday, December 06, 2000 6:20 PM
> Subject: Re: [Dynapi-Dev] DynAPI build, Splitting files
> 
> 
> > If there's going to be any splitting, I think it should 
> only be done in
> > the core files and maybe some of the heavier extensions.  
> I'd rather not
> > have to create split versions of a widget; at that point, 
> it stops being
> > cross-browser, so why bother having an API? It would be 
> difficult enough
> > just to maintain the core files for all browsers.
> >
> > --
> > scott andrew lepera
> > -----------------------------------
> > web stuff:     www.scottandrew.com
> > music stuff:   www.walkingbirds.com
> > _______________________________________________
> > Dynapi-Dev mailing list
> > Dyn...@li...
> > http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
> 
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
>