dynapi-dev

[Dynapi-Dev] Freeing Memory

[Eytan H. <ey...@tr...>]

Since IE is way more popular I started with it. I was wrong with my
assumption that nullifying objects (not even talking about html
elements(layers)) does the whole thing. Let me tell you what I discovered:
if you create 10000 small object and then nullify them nothing happens but
when you recreate them still the memory stays stable. I want to test replace
"= null" with "= [];" maybe that will help.
Identified positive freeing of memory when changing url. Now you all may
say: "so what this sux we can't force them to change url!!" it might be ok
if we design such a system(this design fits well with the talks about a new
API"
We create a framed page
one called RAM and one regular one where you place your project.
In the RAM page there is a method called createObject which does the
following:
* takes the type of object expected
* adds a new object of that type to an array called mem
* returns the index
then on the regular page we say
i = createObject(DynLayer);
myDynLayer = parent.frames[0].mem[i];
(there will be a shortcut to parent.frames[0]).

Then when we want to free mem we pass the mem array to the main frame change
the url to an empty page and reassign the mem array.

Not even sure if this system works. Gonna try it now anyone else got ideas?

8an

RE: [Dynapi-Dev] Freeing Memory

[Pascal B. <pa...@dy...>]

so on a url change everything is freed?

couldn't we then check for a on window close or window blur event? (not sure
if these are available).. in that case we could do a fast url change or
something (again, not sure if that's possible)

Pascal Bestebroer
pa...@dy...
http://www.dynamic-core.net

> -----Oorspronkelijk bericht-----
> Van: dyn...@li...
> [mailto:dyn...@li...]Namens Eytan Heidingsfeld
> Verzonden: dinsdag 20 februari 2001 20:18
> Aan: Dynapi-Dev
> Onderwerp: [Dynapi-Dev] Freeing Memory
>
>
> Since IE is way more popular I started with it. I was wrong with my
> assumption that nullifying objects (not even talking about html
> elements(layers)) does the whole thing. Let me tell you what I discovered:
> if you create 10000 small object and then nullify them nothing happens but
> when you recreate them still the memory stays stable. I want to
> test replace
> "= null" with "= [];" maybe that will help.
> Identified positive freeing of memory when changing url. Now you all may
> say: "so what this sux we can't force them to change url!!" it might be ok
> if we design such a system(this design fits well with the talks
> about a new
> API"
> We create a framed page
> one called RAM and one regular one where you place your project.
> In the RAM page there is a method called createObject which does the
> following:
> * takes the type of object expected
> * adds a new object of that type to an array called mem
> * returns the index
> then on the regular page we say
> i = createObject(DynLayer);
> myDynLayer = parent.frames[0].mem[i];
> (there will be a shortcut to parent.frames[0]).
>
> Then when we want to free mem we pass the mem array to the main
> frame change
> the url to an empty page and reassign the mem array.
>
> Not even sure if this system works. Gonna try it now anyone else
> got ideas?
>
> 8an
>
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev
>

Re[2]: [Dynapi-Dev] Freeing Memory

[Robert R. <rra...@ya...>]

You could possibly load the same url with a unique paramater passed in the
url.  I have yet to try this though.

-- 
// Robert Rainwater

On 2/20/2001, 2:27:22 PM EST, Pascal wrote about "[Dynapi-Dev] Freeing Memory":

> so on a url change everything is freed?

> couldn't we then check for a on window close or window blur event? (not sure
> if these are available).. in that case we could do a fast url change or
> something (again, not sure if that's possible)

> Pascal Bestebroer
> pa...@dy...
> http://www.dynamic-core.net

>> -----Oorspronkelijk bericht-----
>> Van: dyn...@li...
>> [mailto:dyn...@li...]Namens Eytan Heidingsfeld
>> Verzonden: dinsdag 20 februari 2001 20:18
>> Aan: Dynapi-Dev
>> Onderwerp: [Dynapi-Dev] Freeing Memory
>>
>>
>> Since IE is way more popular I started with it. I was wrong with my
>> assumption that nullifying objects (not even talking about html
>> elements(layers)) does the whole thing. Let me tell you what I discovered:
>> if you create 10000 small object and then nullify them nothing happens but
>> when you recreate them still the memory stays stable. I want to
>> test replace
>> "= null" with "= [];" maybe that will help.
>> Identified positive freeing of memory when changing url. Now you all may
>> say: "so what this sux we can't force them to change url!!" it might be ok
>> if we design such a system(this design fits well with the talks
>> about a new
>> API"
>> We create a framed page
>> one called RAM and one regular one where you place your project.
>> In the RAM page there is a method called createObject which does the
>> following:
>> * takes the type of object expected
>> * adds a new object of that type to an array called mem
>> * returns the index
>> then on the regular page we say
>> i = createObject(DynLayer);
>> myDynLayer = parent.frames[0].mem[i];
>> (there will be a shortcut to parent.frames[0]).
>>
>> Then when we want to free mem we pass the mem array to the main
>> frame change
>> the url to an empty page and reassign the mem array.
>>
>> Not even sure if this system works. Gonna try it now anyone else
>> got ideas?
>>
>> 8an
>>
>>
>> _______________________________________________
>> Dynapi-Dev mailing list
>> Dyn...@li...
>> http://lists.sourceforge.net/lists/listinfo/dynapi-dev
>>


> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev


----------------------
DynAPI Snapshots: http://dynapi.sourceforge.net/snapshot/
DynAPI Homepage: http://dynapi.sourceforge.net/

Re: [Dynapi-Dev] Freeing Memory

[Raymond S. <dst...@or...>]

I'm really beginning to think there are two sides to this issue.

1)  Design Methodology.
2)  Code Optimization.

1) Eytan eluded to this here, "and then nullify them nothing happens but
when you recreate them still the memory stays stable".  Today most sites are
page based, and I think within a common site URL browsers attempt to "hold
history active" till you leave to an all new destination, then purge memory.

Everything I have been trying to do is based on using the DynAPI to create a
single interface linked to a dynamically created, updated and evolving site.
Think of the JS as providing "interface" only.  Then you would use dynamic
content engines to pump new content into "reusable components" using set"xx"
methods (heck you could even reskin an object on the fly).  This is the
direction the web is moving anyway with CSS and XML anyway.

There's no reason you couldn't initialize a series of display widgets then
call them in, resize them and modify content based on user activities.  I
think page based browsing + DynAPI (with any level of pizzazz) is a recipe
for failure.  It will eventually overload the system since every page is
going to want it's own widget set.  Design would be based on creating sites
with as tight a "widget depth (how many total layers)" as possible.  Reuse
widgets (if possible) prior to creating new instances of a prototype.

2) Optimization.  I came from a game developer www.angelstudios.com.  I was
COO and I found the business of "making games" slow and boring.  The idea of
waiting and working 2 years to see if you have a winner to only see the
"bounty" get slyly skimmed into the publishers pockets grows old fast).
Hence, I left the Industry for the fast paced insanity of the web.  But game
developers are optimization freaks, they have to be.

I did a little research (I wasn't a programmer, I made sure they didn't eat
to many Twinkies during a specified month because at Angel we bought all the
Twinkies for our employees; kept them coding longer), and just from a
"tricks of the trade standpoint" our code could be significantly optimized
with a skew towards the Pentium processor set.  I'm sure with additional
research we could learn even more.  Here's what I found so far:

a)  API's, in general, are non-optimizied.  DirectX works (as an API)
because it was designed to be as "thin" as possible.

b)  Use global variables.  Don't use parameters for allot of time-critical
functions, instead use a global parameter passing area.  Example:

    void Plot(init x, init y, init color) {
    // plots a pixel on the screen
    video_buffer{x +y*MEMORY_PITCH] = color;
    }

optimized

    int gx,gy,gz,color;  //define globals

    void Plot_G(void) {
    video_buffer[gx + gy*MEMORY_PITCH] = color;
    }

I realize we are an API, but implementing aspects of this where appropriate
will help.

2)  Always use 32-bit variables rather then 8- or 16-bit.  The Pentium and
later processors are all 32-bit.  This means they don't like 8- or 16-bit
data words, and in fact, smaller data can slow them down due to caching and
other related memory anomalies.  Example:

    struct CPOINT {
    short x,y;
    unsigned char c;
    }

Optimized

    struct CPOINT {
    int x,y;
    int c;
    }

I don't think this applies a great deal to the current API but I am sharing
it anyway.

3)  Program in a RISC-like (reduced instruction set computer) manner.  In
other words make code simple rather then complex.  Pentium class processors
like simple instructions rather then complex ones.  Longer simpler code is
faster then short complex code structures.  Example:

    if ((x+=(2*buffer[index++])>10) {
    do stuff...
    }

Optimized

    x+=(2*buffer[index]);
    index++;

    if (x>10) {
    do stuff...
    }

We do sin here a bit....

4)  Use binary shifts for simple multiplication of integers by powers of 2.
Since all data in a computer is stored in a binary form, shifting the bit
pattern to the left or right is equivalent to multiplication or division.
Example:

    int y_pos = 10:
    // multiple y_pos by 64
    y_pos = (y_pos << 6);  //2^6=64

Similarly,

    //to divide y_pos by 8
    y_pos = (y_pos >> 3); // 1/2^3 = 1/8

Disadvantage... confusing code to some.

5)  Write efficient algorithms.

6)  Don't write complex data structures for simple objects.

7)  Don't go crazy with inheritance and layers of software.  Keep the base
as lean as possible.

8)   The Pentium-class processors use an internal data and code cache.  Be
aware of this, and try to keep the size of your functions relatively small
so they can fit into the cache (16KB-32KB+).  Store data in an accessible
way, it minimizes cache thrashing and main memory or secondary cache access,
which is 10 times slower than the internal cache.

9) Use precomputed "look-up tables" when possible.


So, I think that freeing memory and optimizing speed will be the marriage of
a quality site design/interface and a well constructed code base to draw
from.  While some users will elect to take a more conventional path I think
this will ultimately lead the the best "final result".  But hey!  I'm just a
designer...

Ray

Re: [Dynapi-Dev] Freeing Memory

[Doug M. <do...@cr...>]

Another tip is not to over do it with the 'snazz'.
The problem with my orgigional Demo site was that I used DynAPI wherever
possible.
I have found that one can use simple HTML or plain javascript
in a lot of places (such as for roll-over menus, or 'dynamic' content).
Which in turn speeds up the site and resduces the mem-footprint.

Doug
----- Original Message -----
From: "Raymond Smith" <dst...@or...>
To: <dyn...@li...>
Sent: Tuesday, February 20, 2001 12:51 PM
Subject: Re: [Dynapi-Dev] Freeing Memory


> I'm really beginning to think there are two sides to this issue.
>
> 1)  Design Methodology.
> 2)  Code Optimization.
>
> 1) Eytan eluded to this here, "and then nullify them nothing happens but
> when you recreate them still the memory stays stable".  Today most sites
are
> page based, and I think within a common site URL browsers attempt to "hold
> history active" till you leave to an all new destination, then purge
memory.
>
> Everything I have been trying to do is based on using the DynAPI to create
a
> single interface linked to a dynamically created, updated and evolving
site.
> Think of the JS as providing "interface" only.  Then you would use dynamic
> content engines to pump new content into "reusable components" using
set"xx"
> methods (heck you could even reskin an object on the fly).  This is the
> direction the web is moving anyway with CSS and XML anyway.
>
> There's no reason you couldn't initialize a series of display widgets then
> call them in, resize them and modify content based on user activities.  I
> think page based browsing + DynAPI (with any level of pizzazz) is a recipe
> for failure.  It will eventually overload the system since every page is
> going to want it's own widget set.  Design would be based on creating
sites
> with as tight a "widget depth (how many total layers)" as possible.  Reuse
> widgets (if possible) prior to creating new instances of a prototype.
>
> 2) Optimization.  I came from a game developer www.angelstudios.com.  I
was
> COO and I found the business of "making games" slow and boring.  The idea
of
> waiting and working 2 years to see if you have a winner to only see the
> "bounty" get slyly skimmed into the publishers pockets grows old fast).
> Hence, I left the Industry for the fast paced insanity of the web.  But
game
> developers are optimization freaks, they have to be.
>
> I did a little research (I wasn't a programmer, I made sure they didn't
eat
> to many Twinkies during a specified month because at Angel we bought all
the
> Twinkies for our employees; kept them coding longer), and just from a
> "tricks of the trade standpoint" our code could be significantly optimized
> with a skew towards the Pentium processor set.  I'm sure with additional
> research we could learn even more.  Here's what I found so far:
>
> a)  API's, in general, are non-optimizied.  DirectX works (as an API)
> because it was designed to be as "thin" as possible.
>
> b)  Use global variables.  Don't use parameters for allot of time-critical
> functions, instead use a global parameter passing area.  Example:
>
>     void Plot(init x, init y, init color) {
>     // plots a pixel on the screen
>     video_buffer{x +y*MEMORY_PITCH] = color;
>     }
>
> optimized
>
>     int gx,gy,gz,color;  //define globals
>
>     void Plot_G(void) {
>     video_buffer[gx + gy*MEMORY_PITCH] = color;
>     }
>
> I realize we are an API, but implementing aspects of this where
appropriate
> will help.
>
> 2)  Always use 32-bit variables rather then 8- or 16-bit.  The Pentium and
> later processors are all 32-bit.  This means they don't like 8- or 16-bit
> data words, and in fact, smaller data can slow them down due to caching
and
> other related memory anomalies.  Example:
>
>     struct CPOINT {
>     short x,y;
>     unsigned char c;
>     }
>
> Optimized
>
>     struct CPOINT {
>     int x,y;
>     int c;
>     }
>
> I don't think this applies a great deal to the current API but I am
sharing
> it anyway.
>
> 3)  Program in a RISC-like (reduced instruction set computer) manner.  In
> other words make code simple rather then complex.  Pentium class
processors
> like simple instructions rather then complex ones.  Longer simpler code is
> faster then short complex code structures.  Example:
>
>     if ((x+=(2*buffer[index++])>10) {
>     do stuff...
>     }
>
> Optimized
>
>     x+=(2*buffer[index]);
>     index++;
>
>     if (x>10) {
>     do stuff...
>     }
>
> We do sin here a bit....
>
> 4)  Use binary shifts for simple multiplication of integers by powers of
2.
> Since all data in a computer is stored in a binary form, shifting the bit
> pattern to the left or right is equivalent to multiplication or division.
> Example:
>
>     int y_pos = 10:
>     // multiple y_pos by 64
>     y_pos = (y_pos << 6);  //2^6=64
>
> Similarly,
>
>     //to divide y_pos by 8
>     y_pos = (y_pos >> 3); // 1/2^3 = 1/8
>
> Disadvantage... confusing code to some.
>
> 5)  Write efficient algorithms.
>
> 6)  Don't write complex data structures for simple objects.
>
> 7)  Don't go crazy with inheritance and layers of software.  Keep the base
> as lean as possible.
>
> 8)   The Pentium-class processors use an internal data and code cache.  Be
> aware of this, and try to keep the size of your functions relatively small
> so they can fit into the cache (16KB-32KB+).  Store data in an accessible
> way, it minimizes cache thrashing and main memory or secondary cache
access,
> which is 10 times slower than the internal cache.
>
> 9) Use precomputed "look-up tables" when possible.
>
>
> So, I think that freeing memory and optimizing speed will be the marriage
of
> a quality site design/interface and a well constructed code base to draw
> from.  While some users will elect to take a more conventional path I
think
> this will ultimately lead the the best "final result".  But hey!  I'm just
a
> designer...
>
> Ray
>
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev


---
Outgoing mail is certified Virus Free by AVG Free Edition
Download at: http://www.grisoft.com/html/us_index.cfm
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.231 / Virus Database: 112 - Release Date: 2/12/01

Re: [Dynapi-Dev] Freeing Memory

[Jeff G. <je...@we...>]

This kind of thing becomes troublesome in javascript.

For instance, bit shifting for multiples of 2 is great.... except that all my
tests show that it offers no advantages, and, in fact, is sometimes slower in
javascript than just multiplying by 2. (If anyone wants to see a demo of this I
will post it on my site).

Lookup tables fair a little better, but their gain over straight calculations
only seems to be about 3 or 4 percent at most (I need to check this more
thouroughly).



Jeff Greenberg
je...@we...

Raymond Smith wrote:

> I'm really beginning to think there are two sides to this issue.
>
> 1)  Design Methodology.
> 2)  Code Optimization.
>
> 1) Eytan eluded to this here, "and then nullify them nothing happens but
> when you recreate them still the memory stays stable".  Today most sites are
> page based, and I think within a common site URL browsers attempt to "hold
> history active" till you leave to an all new destination, then purge memory.
>
> Everything I have been trying to do is based on using the DynAPI to create a
> single interface linked to a dynamically created, updated and evolving site.
> Think of the JS as providing "interface" only.  Then you would use dynamic
> content engines to pump new content into "reusable components" using set"xx"
> methods (heck you could even reskin an object on the fly).  This is the
> direction the web is moving anyway with CSS and XML anyway.
>
> There's no reason you couldn't initialize a series of display widgets then
> call them in, resize them and modify content based on user activities.  I
> think page based browsing + DynAPI (with any level of pizzazz) is a recipe
> for failure.  It will eventually overload the system since every page is
> going to want it's own widget set.  Design would be based on creating sites
> with as tight a "widget depth (how many total layers)" as possible.  Reuse
> widgets (if possible) prior to creating new instances of a prototype.
>
> 2) Optimization.  I came from a game developer www.angelstudios.com.  I was
> COO and I found the business of "making games" slow and boring.  The idea of
> waiting and working 2 years to see if you have a winner to only see the
> "bounty" get slyly skimmed into the publishers pockets grows old fast).
> Hence, I left the Industry for the fast paced insanity of the web.  But game
> developers are optimization freaks, they have to be.
>
> I did a little research (I wasn't a programmer, I made sure they didn't eat
> to many Twinkies during a specified month because at Angel we bought all the
> Twinkies for our employees; kept them coding longer), and just from a
> "tricks of the trade standpoint" our code could be significantly optimized
> with a skew towards the Pentium processor set.  I'm sure with additional
> research we could learn even more.  Here's what I found so far:
>
> a)  API's, in general, are non-optimizied.  DirectX works (as an API)
> because it was designed to be as "thin" as possible.
>
> b)  Use global variables.  Don't use parameters for allot of time-critical
> functions, instead use a global parameter passing area.  Example:
>
>     void Plot(init x, init y, init color) {
>     // plots a pixel on the screen
>     video_buffer{x +y*MEMORY_PITCH] = color;
>     }
>
> optimized
>
>     int gx,gy,gz,color;  //define globals
>
>     void Plot_G(void) {
>     video_buffer[gx + gy*MEMORY_PITCH] = color;
>     }
>
> I realize we are an API, but implementing aspects of this where appropriate
> will help.
>
> 2)  Always use 32-bit variables rather then 8- or 16-bit.  The Pentium and
> later processors are all 32-bit.  This means they don't like 8- or 16-bit
> data words, and in fact, smaller data can slow them down due to caching and
> other related memory anomalies.  Example:
>
>     struct CPOINT {
>     short x,y;
>     unsigned char c;
>     }
>
> Optimized
>
>     struct CPOINT {
>     int x,y;
>     int c;
>     }
>
> I don't think this applies a great deal to the current API but I am sharing
> it anyway.
>
> 3)  Program in a RISC-like (reduced instruction set computer) manner.  In
> other words make code simple rather then complex.  Pentium class processors
> like simple instructions rather then complex ones.  Longer simpler code is
> faster then short complex code structures.  Example:
>
>     if ((x+=(2*buffer[index++])>10) {
>     do stuff...
>     }
>
> Optimized
>
>     x+=(2*buffer[index]);
>     index++;
>
>     if (x>10) {
>     do stuff...
>     }
>
> We do sin here a bit....
>
> 4)  Use binary shifts for simple multiplication of integers by powers of 2.
> Since all data in a computer is stored in a binary form, shifting the bit
> pattern to the left or right is equivalent to multiplication or division.
> Example:
>
>     int y_pos = 10:
>     // multiple y_pos by 64
>     y_pos = (y_pos << 6);  //2^6=64
>
> Similarly,
>
>     //to divide y_pos by 8
>     y_pos = (y_pos >> 3); // 1/2^3 = 1/8
>
> Disadvantage... confusing code to some.
>
> 5)  Write efficient algorithms.
>
> 6)  Don't write complex data structures for simple objects.
>
> 7)  Don't go crazy with inheritance and layers of software.  Keep the base
> as lean as possible.
>
> 8)   The Pentium-class processors use an internal data and code cache.  Be
> aware of this, and try to keep the size of your functions relatively small
> so they can fit into the cache (16KB-32KB+).  Store data in an accessible
> way, it minimizes cache thrashing and main memory or secondary cache access,
> which is 10 times slower than the internal cache.
>
> 9) Use precomputed "look-up tables" when possible.
>
> So, I think that freeing memory and optimizing speed will be the marriage of
> a quality site design/interface and a well constructed code base to draw
> from.  While some users will elect to take a more conventional path I think
> this will ultimately lead the the best "final result".  But hey!  I'm just a
> designer...
>
> Ray
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev

RE: [Dynapi-Dev] Freeing Memory

[Eytan H. <ey...@tr...>]

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

Re: [Dynapi-Dev] Freeing Memory

[Raymond S. <dst...@or...>]

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" <ey...@tr...>
To: <dyn...@li...>
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
> Dyn...@li...
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev
>

Re: [Dynapi-Dev] Freeing Memory

[Doug M. <do...@cr...>]

How about a multi-user collaborative 'whiteboard' app?

If I see enough interest I could build one fairly quikly..


----- Original Message -----
From: "Raymond Smith" <dst...@or...>
To: <dyn...@li...>
Sent: Tuesday, February 20, 2001 2:10 PM
Subject: Re: [Dynapi-Dev] Freeing Memory


> 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" <ey...@tr...>
> To: <dyn...@li...>
> 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
> > Dyn...@li...
> > http://lists.sourceforge.net/lists/listinfo/dynapi-dev
> >
>
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev


---
Outgoing mail is certified Virus Free by AVG Free Edition
Download at: http://www.grisoft.com/html/us_index.cfm
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.231 / Virus Database: 112 - Release Date: 2/12/01

Re: [Dynapi-Dev] Freeing Memory

[Raymond S. <dst...@or...>]

That or what Robert eluded to.  Someway of remote notation of a single
central document.

----- Original Message -----
From: "Doug Melvin" <do...@cr...>
To: <dyn...@li...>
Sent: Tuesday, February 20, 2001 5:14 PM
Subject: Re: [Dynapi-Dev] Freeing Memory


> How about a multi-user collaborative 'whiteboard' app?
>
> If I see enough interest I could build one fairly quikly..
>
>
> ----- Original Message -----
> From: "Raymond Smith" <dst...@or...>
> To: <dyn...@li...>
> Sent: Tuesday, February 20, 2001 2:10 PM
> Subject: Re: [Dynapi-Dev] Freeing Memory
>
>
> > 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" <ey...@tr...>
> > To: <dyn...@li...>
> > 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
> > > Dyn...@li...
> > > http://lists.sourceforge.net/lists/listinfo/dynapi-dev
> > >
> >
> >
> > _______________________________________________
> > Dynapi-Dev mailing list
> > Dyn...@li...
> > http://lists.sourceforge.net/lists/listinfo/dynapi-dev
>
>
> ---
> Outgoing mail is certified Virus Free by AVG Free Edition
> Download at: http://www.grisoft.com/html/us_index.cfm
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.231 / Virus Database: 112 - Release Date: 2/12/01
>
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev
>

Re: [Dynapi-Dev] Freeing Memory

[Doug M. <do...@cr...>]

Which is what I ment..
:-)

----- Original Message -----
From: "Raymond Smith" <dst...@or...>
To: <dyn...@li...>
Sent: Tuesday, February 20, 2001 2:21 PM
Subject: Re: [Dynapi-Dev] Freeing Memory


> That or what Robert eluded to.  Someway of remote notation of a single
> central document.
>
> ----- Original Message -----
> From: "Doug Melvin" <do...@cr...>
> To: <dyn...@li...>
> Sent: Tuesday, February 20, 2001 5:14 PM
> Subject: Re: [Dynapi-Dev] Freeing Memory
>
>
> > How about a multi-user collaborative 'whiteboard' app?
> >
> > If I see enough interest I could build one fairly quikly..
> >
> >
> > ----- Original Message -----
> > From: "Raymond Smith" <dst...@or...>
> > To: <dyn...@li...>
> > Sent: Tuesday, February 20, 2001 2:10 PM
> > Subject: Re: [Dynapi-Dev] Freeing Memory
> >
> >
> > > 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" <ey...@tr...>
> > > To: <dyn...@li...>
> > > 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
> > > > Dyn...@li...
> > > > http://lists.sourceforge.net/lists/listinfo/dynapi-dev
> > > >
> > >
> > >
> > > _______________________________________________
> > > Dynapi-Dev mailing list
> > > Dyn...@li...
> > > http://lists.sourceforge.net/lists/listinfo/dynapi-dev
> >
> >
> > ---
> > Outgoing mail is certified Virus Free by AVG Free Edition
> > Download at: http://www.grisoft.com/html/us_index.cfm
> > Checked by AVG anti-virus system (http://www.grisoft.com).
> > Version: 6.0.231 / Virus Database: 112 - Release Date: 2/12/01
> >
> >
> > _______________________________________________
> > Dynapi-Dev mailing list
> > Dyn...@li...
> > http://lists.sourceforge.net/lists/listinfo/dynapi-dev
> >
>
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev


---
Outgoing mail is certified Virus Free by AVG Free Edition
Download at: http://www.grisoft.com/html/us_index.cfm
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.231 / Virus Database: 112 - Release Date: 2/12/01