[Dynapi-Dev] Splitting the API?

[Brandon M. <bnd...@ho...>]

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