I'm sure there have been numerous responses to this email,
but I am just back after a week of using the DynAPI in a 22 million$
product..
They had never considered using any DHTML library and where surprised at
the capabilities to say the least.
About Strider's messag:
1) Code-Branching: While this can be insanly difficult to maintain, the
benifits are more
than adaquate to make of for any headaches caused.
One example of 'branch specific' coding: In IE you can use Try...catch. In
NS you can not.
An IE branch would be able to have VERY advanced error handling, and would
be
able to adapt to timing issues, such as one frame not loading quite as fast
as another.. ect.
This would also allow us to 'shrink' the API further.. for instance a DOM
branch would
,by it's very nature, be far smaller than any other.
This would also make it far eiser to meet the '35k' limit being imposed on
systems that need to
be freindly with slower connections.
If you think slower connections are a thing of the past, netPCS is
connecting a good many users
to the internet for the first time in Africa, _BUT_ this is across a
wireless network with speeds close to that
of a 28.8 modem.
2)INTERNALS: I agree taht the code itself can be phisically trimmed down
quite a bit.
Not only can we make 'internal' variable and such smaller, but we could make
a real effort to make the code
'compression' ready, IE; put semi-colons (;) where they are needed as well
as using {} (curly-braces) where we can so that the
code can be packed with a util such as jsPack. The API at the moment when
jar'd comes to about 13k.
a branched+compression-optimizes version could go as low as 2-4 k. (an
estimate based on past optimization experience)
Another good point made by Strider is 'commenting' we don't do enough of it
(myself included).
You don't need to worry about code size, as the same util which compacts the
code would strip out the comments, not only that,
but by practising a commenting/documentation standard we would be able to
produce up-to-date documentation for the api at the click of a button.
That's my 2.54 cents worth.
Later.
----- Original Message -----
From: "Digital Strider" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, July 21, 2001 11:58 AM
Subject: [Dynapi-Dev] Pondering the "API"...
> I've been off in the land of Java the past few months exploring it's
> server-side capabilities along side other open source server-side
solutions.
>
> Recently, I've been pondering the client-side again and the DynAPI. I
think
> it's time for an "evolution". I'll iterate through what I'm proposing.
>
> 1) TREE-BRANCHING the API. This includes splitting the current offering
> into NS/IE legs as well as adding a new "DOM" leg. This doesn't imply
> extending the current API into the DOM branch as much as using the same
> "interfaces" for the object/method/property calls while implementing
> internals in "nodal speak". I believe this is what object based
> encapsulation is all about.
>
> This will significantly improve and extend the life of this API. The
issue
> is based on the fact that DOM compliant browser's are reaching a level of
> saturation that warrant taking advantage DOM's simplicity.
>
> Additionally, a DOM only world is still a long way off. I recently read
> that allot of corporations spec NS4 due to strategic issues with Microsoft
> and even a 5% NS level in the market will turn a client away from a DOM
only
> solution.
>
> ADVANTAGES
>
> Branching will trim allot of the fat from this API on a client/load basis.
> I know this has been rattled around before. Forget all debilitate
> foundations and look at it only from a client/service standpoint and the
> solution is obvious. Break it up and stop forcing A to download B. Also
> adding "DOM's" branch will add a third leg, C to further muddle the pie.
>
> Adding a DOM branch will go a long way towards embracing all the "other"
> browsers that are pursuing DOM compliance, not DHTML compliance. Branches
A
> and B will soon start to gather dust, but at least they are part of an
> overall solution.
>
> 2) INTERNALS. If we elect to pursue this "evolution" it offers allot of
> opportunity to "trim" in other areas. We use some of the "biggest" words
I
> have ever seen, over and over again (eventListener, deleteChildElements,
> DynDocument, addEventListener, getParentComponent.
>
> Two solutions come to mind. 1) trim the internals (evLis, deChElm, DDoc,
> adEvLis, etc..) and wrap them in the old calls, 2) change the internal's
and
> the call's which would require rework on implemented sites. Since we
don't
> have an IDE (I doubt we ever will) I drool at the potential of typing
"evLis
> or adEvLis" over and over again.
>
> While we lean the language we should also enrich the "comments/commenting"
> within, including definition of above. I truly think the combination of
> split-branching the API along with a good language leaning will go miles
> towards creating a very functionally lean and usable API with headroom for
> tomorrow (DOM branch). Now add smart management on the server, including
> dynamic/static compression and the size of this API becomes
inconsequential.
>
> Fire away boy...
>
> DS
>
> PS - On top of all the above this "group" as splintered and lost it's
fire.
> There is no reason for planned extinction. This API still has the ability
> to deliver a multi-branch solution well into the future.
>
>
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.265 / Virus Database: 137 - Release Date: 7/18/2001
>
>
> _______________________________________________
> 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
