The three strongest "thread" categories have been:
1) Speed optimization
2) Dynamic content
3) API overall construction method
NOTE: I left DynBuilder out because I think that is a sister initiative
that wraps around whatever we elect to make the DynAPI do.
I really think all three of these are parts of a single "new" whole we
should be targeting for the DynAPI3. One eludes to and dictates
requirements for the others. Any way, this is a bit premature since I am
still trying to get this stack of paper into a single presentable form.
But the first fundamental question we need to ask ourselves about the next
generation of this API is, "What we intend it to be used for."
(1) A set of surface enhancing widgets for general layman use. Menu,
windows, navigation devices.
(2) A series of linkable components (server and/or client) that can manage
and present information dynamically within the library of server-side
widgets(1).
(3) Both. An API that allows the generalist to enhance their site using the
API that also has hooks developed into it that allows a more serious
implementation embracing the whole information interchange circuit; client
to server-side. As Robert has pointed out these "hooks" could be developed
to allow the user language implementation flexibility.
Answer this question, and it will go along ways to defining what we do and
focus on next.
Ray
----- Original Message -----
From: "Eytan Heidingsfeld" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, February 20, 2001 1:36 PM
Subject: RE: [Dynapi-Dev] Freeing Memory
> All those tips are great for optimizing performance in compiled code
running
> on Pentium machines. Small problem we here are interpreted code. All code
is
> evaluated at run time. Anyway that kind of optimization is to try and snip
> off milliseconds. Here we are talking about seconds going to waste not 1
> millisecond faster or slower.
>
> About the other idea of using one set of objects and updating. I like it
> BUT:
> * We need some sort of fail-proof content delivery mechanism.
> * If you want this then you definitely need to restructure the API to
> provide an Application like interface with mem manegment.
>
> 8an
>
>
> _______________________________________________
> 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
