Re: [Dynapi-Dev] Splitting the API?

[Doug M. <do...@cr...>]

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