That or what Robert eluded to. Someway of remote notation of a single
central document.
----- Original Message -----
From: "Doug Melvin" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
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" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> 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" <[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
>
>
> ---
> 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
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev
>
_______________________________________________
Dynapi-Dev mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/dynapi-dev
