Re: [Dynapi-Dev] Splitting the API?

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

I cannot do that yet.
I can, though, assist in guiding you in whatever efforts you may endevor.

----- Original Message -----
From: "Doug Melvin" <do...@cr...>
To: <dyn...@li...>
Sent: Thursday, November 30, 2000 8:13 PM
Subject: Re: [Dynapi-Dev] Splitting the API?

> How about posting your efforts.. an increase in speed and stability is
> something I think we could all use.. (well, I could anyways..)
>
>
> ----- Original Message -----
> From: "Brandon Myers" <bnd...@ho...>
> To: <dyn...@li...>
> Sent: Thursday, November 30, 2000 11:58 AM
> Subject: [Dynapi-Dev] Splitting the API?
>
>
> > I don't know how splitting the API came out of object inheritance. Which
> are
> > 2 totally sperate issues... but here goes my wordy opinion...
> >
> > I have completed splitting the API into parts for IE and NS, even to
their
> > specific versions. I have nodiced a 10x increase in speed. And a great
> > increase in stability.
> >
> > If the community was to appoint a maintainer for each browser, someone
who
> > is highly sufficient in the capabilities of the browser, then they can
> > optimize their versions without fear of gumming up the works for other
> > browsers and platforms.
> >
> > The other drawback, from what I see, is that there would be a need to
> > maintain a list of files for each browser type. Or, what files are
common,
> > and what files are specific for each browser. I have solved this
problem,
> > but the requirement for maintaing a list of files for each category, or
> > browser, is still a necessity. That, although, gives a benifit to the
API.
> > Now, we sould no-longer have to specify the fill path of the script
file.
> > Just the name of the script would include all necessary files. If, for
> > example, the DynLayer object where to be split, there coujld be 5
possible
> > files generated.
> > 1: The common parts to all browsers.
> > 2: IE4
> > 3: IE5
> > 4: NS4
> > 5: DOM compliant.
> >
> > The common part would obviously be the larger, as there is much that is
> > common to both browsers. But if things are done right, the result of the
> > seperation, when both common and the specific browser version is
combined,
> > would be less than the original DynLayer file was before the split. This
I
> > have proved with the version I have enhanced.
> >
> > It becomes quite simple to maintain after a list of standards of what
the
> > API is actually suppoed to provide is made available. It also allows
> > developers who like the API, and wish to target a specific browser
> audience
> > with enhanced features not provided by other brosers, to develop highly
> > advcanced sites using the API together with their own proprietary
> additions.
> > These additions are made easier due to the "pluggable" nature of the
> > resulting split.
> >
> > Supporting browser specific implementation of features available in both
> > browsers also becomes easier. Things such as audio support, a file that
> > glues java objects to javascript events, and vice versa. These features
> > become trivial when this path is followed.
> >
> > I'm not staying it will be easy. But I believe that the benifits would
> > outway the work it would entail.
> > ----- Original Message -----
> > From: "Abel Eduardo Cantu Salas" <abe...@al...>
> > To: <dyn...@li...>
> > Sent: Thursday, November 30, 2000 2:00 PM
> > Subject: RE: [Dynapi-Dev] inheritance crusade / SuperClass stuff
> >
> >
> > > > But isn't it better to use optimised versions for the browser, not
> > > > the one for all?
> > >
> > > It sound very interesting indeed Alexey... then you can also create
new
> js
> > > for newer browsers whithout any need to touch other js (just like dlls
> or
> > > device drivers, you'll load what you need); it will allow you to
reduce
> > the
> > > amount of code that the client most download and most important than
> that
> > is
> > > the fact that this code will be really very optimised. However this
has
> an
> > > important drawback that we most consider:
> > >
> > > Doing this means an extra work in trying to maintain standardized all
> the
> > > APIS for diferent platforms and diferent browsers, id est, if we add
> > > something to an API we must add the same functionality to all other;
and
> > not
> > > just that, separating everything so you can then optimize a lot, could
> > make
> > > easy a loss of control in what is disponible for what platform.
> > >
> > > Im sure we don't want a DynAPI that says: "this is disponible only for
> NS"
> > > or vice versa, then we most work a lot to keep things in the right
path.
> > >
> > > Any opinions or sugestions about this matter?, there is a lot of
> > advantages
> > > and drawbacks in a schema like this...
> > >
> > > -----Original Message-----
> > > From: dyn...@li...
> > > [mailto:dyn...@li...]On Behalf Of Alexey
> > > Medvedev
> > > Sent: Jueves, 30 de Noviembre de 2000 10:42 a.m.
> > > To: dyn...@li...
> > > Subject: Re: Re: Re: [Dynapi-Dev] inheritance crusade / SuperClass
stuff
> > >
> > >
> > > On Thu, 30 Nov 2000, Barre Bizon wrote:
> > >
> > > Yes - I told it is JS_1.3_
> > >
> > > > Another thing... neither the function.call() nor the
> > > > function.apply() method work under IE4+.
> > > > Unfortunately.
> > >
> > > Also add .watch() to the list :-/
> > >
> > >  But isn't it better to use optimised versions for the brouser, not
> > >  the one for all?
> > >
> > >   So main "dynapi" whould be a selector of "dynlayer_ns4.js"
> > > or "dynlayer_ie4.js" but keeping same API?
> > >
> > > I thinks using "new Layer" in NN4 is better then creating
> > >  lots of CSS and <div>-s (memory usage and resistance to Resize):
> > >
> > > http://deep.kiev.ua/JS/WebGram/ - resize resistant without
> > >  any reloads.
> > >
> > > ps. last one i need to make site as one page , with changed layers
> > > Same as www.htmlguru.com is.
> > >
> > > Malx
> > >
> > > _______________________________________________
> > > 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
> >
> >
> >
> >
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/mailman/listinfo/dynapi-dev