This is a very old "idea" the thread repository has a wealth of debate
surrounding API as a single construct or API as a self-assembling library.
API component management has always been the issue that knocked the knees
out from under it. Since this is an amorphic open-source group it's working
body of developers tends to shift over time with the exception of a very few
core people (Pascal, Rainwater, Jordi).
----- Original Message -----
From: "Strolia-Davis Christopher Contr MSG MAM"
<[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, February 27, 2001 1:38 PM
Subject: RE: [Dynapi-Dev] not so sure about this anymore
> I just had a thought recently that could be useful for future versions of
> the DynAPI, and could perhaps eliminate this problem of constantly
evolving
> browsers.
>
> I know I am not one of the developers on this project, so forgive me if I
am
> out of line here.
>
> The idea I had would be to have a sort of document object model for
DynAPI,
>
> Develop the functions and objects separately for each system.
>
> In the very beginning, you would check which system the user has and
> automatically link to the appropriate script pages kind of like you do
when
> you are requesting specific libraries now in DynAPI.
>
> This way you could code specifically for a given platform, and anybody who
> really understands that platform can do the coding, and those people who
> don't know EVERY platform won't feel so left out.
>
> Also, bandwidth should be saved since you are not loading a whole bunch of
> cross browser code, but only the code needed for this browser.
>
> for example,
>
> You could have a script folder for
> Netscape 4.0
> Netscape 6.0
> IE 4.0
> IE 5.0
> IE 5.5 , etc.
>
> You could copy and paste certain libs if they are identical in two
different
> versions
>
> When a user accesses the site, the DynAPI would check their browser, and
> then load the scripts from the appropriate folder.
>
> You may want to make some configuration available for what to do for
> unsupported systems or something. Like pop up a message.
>
> The cool thing about this is that you can create code that accesses all
the
> cool features from each browser, and just make sure it does it the "SAME
> WAY" on all browsers that can support that functionality. If someone
wants
> to support more browsers on their site, they may have to give up some
> functions that aren't available to all the browsers they support, but at
> least those functions will be available for when they decide to no longer
> support say Netscape 4.0, and all they would need to do is add netscape to
> their unsupported browsers list.
>
> It's hard to clarify this in a message, so I will attempt to come up with
> some sort of demo in the near future.
>
> Bye for now,
>
> Chris Strolia-Davis
>
> |-----Original Message-----
> |From: Matthew A. Shirey [mailto:[EMAIL PROTECTED]]
> |Sent: Tuesday, February 27, 2001 3:49 PM
> |To: [EMAIL PROTECTED]
> |Subject: RE: [Dynapi-Dev] not so sure about this anymore
> |
> |
> |Heh, I personally have the same attitude as you. Problem is what you
> |are asking for may never happen. DynAPI does not simply help support
> |the older browsers it also bridges the differences in
> |implementation and
> |interpretation of the current standards. Even the most
> |current versions
> |of the browsers do not do things the same way. DynAPI allows us to
> |write one set of code and it sorts out the mess between the browsers.
> |Oh well, that's my input on the subject...
> |
> |-- Matthew
> |
> |
>
> _______________________________________________
> Dynapi-Dev mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev
>
_______________________________________________
Dynapi-Dev mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/dynapi-dev
