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
