Update, for those who follow "the life and times of the rock".
I used DynAPI2++ because it seems an appropriate acronym, in my mind at
least. I hope what follows will add clarity.
I believe the nucleus of the API is very solid and will only get better as
the following are integrated:
1) Resolve "garbage collection" issues (memory leak). I'm 90% sure that
referential circles are the crux of the current API's memory consumption and
inability to release it. Part of this is supported by some recent readings
of mine that actually discussed the use of "reference pointers" to keep
garbage collection from removing an object you may not be done with (not a
problem we are dealing with). This will make more sense later.
2) Fine tune and optimize the code.
3) Learn (as developers) how to effectively "use" this tool because I think
it opens up a world of opportunities and requires an ability to embrace and
adapt subtle paradigm shifts as to how web-environments are designed and
created.
4) As the browser base continues to mature, it will continue to open up new
layers of opportunity. The 5+ browsers are certainly more robust then the
4.0's.
Which leads to the ++ part of DynAPI2++.
As I see it, this API will be used at two levels. First, as a tool to
introduce navigational enhancements to "conventional web pages" and secondly
to serve as a very sophisticated "client interface" to web objects that
extend server-side applications.
Let me clarify what I mean by "conventional web pages". To me these are
static sites up to and including low level 2-tier client/server
architectures (no middleware). This world tends to include PHP, MySQL, PERL
and uses server calls directly to the database, which then responds to the
query.
The next level, is extending the "clients widget interface" to link up with
a web object interface thus allowing for dynamic client interfacing to
dynamic server-side web application interfaces (object to object data
exchange through an adapter or translator). This would open up a world of
new and exciting opportunities. Also, I think it's a critical component to
allowing this API to be extended into whole new areas of market opportunity.
This level is far more complicated and includes DCOM (.NET), RMI, ORB's,
XML, Java and a host of very sophisticated databases.
This is the area that has extreme interest to me because it would allow for
the creation of very sophisticated and dynamic web applications and also
would position this API for what is projected to be the future of
client/server technologies.
The ++ is basically the need (in my mind) to work on the "adapters" that
would allow us to link JS based client interfaces to (eventually) a broad
based variety of successful server-side application architectures.
I'm still researching a lot of areas in the hopes of narrowing down what
might be the first "best" target platform, client/server to begin to flush
out the details and challenge areas. Not even sure that this interests the
current group of developers here, or if it's to abstract and complicated for
a DHTML API.
Anyway, keep you posted. Like to here your input and thoughts also.
Laters,
Ray
_______________________________________________
Dynapi-Dev mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/dynapi-dev
