Re: [Dynapi-Dev] Freeing Memory

[Jordi - I. - M. <jmi...@or...>]

The audience is listening.

Try not to let these not-so-enthusiastic responses get into you. It happens to
everybody: posting the results of many hours of work, expecting at least not to
be ignored, and then receiving nothing but silence.

I believe you're going the right way. Usually people post to disagree because
they feel things are moving towards somewhere they don't like and/or is of no
interest for their personal usage of the API. When things go right then people
is most likely to adopt a confortable attitude.

He who remains silent concedes.

Raymond Smith wrote:

> <emote> pulls out blow torch, flick and ignites a cold blue flame....
>
> First off, I can understand your passion, and if you go all the way back to
> the very first "lets stop and think about it first, then act" post you will
> see that above alpha-next-generation-anything was finish up DynAPI2.
>
> Secondly, beginning discussions (which you should definitely be involved in)
> on the planning stages of the next generation of "this" API is certainly
> appropriate at this time.  The format that was presented was one of
> brushstroke self-appraisal with an eye towards what we would like the next
> evolution of this API to be capable of.
>
> Not one mention of "abandon and run" removing the potential for backward
> compatibility.  Which I think should be a serious consideration in this
> "planning" stage.
>
> At this stage not a single "anything" has been agreed upon.  There have been
> lots of discussions related to super-class this, client-side that.  I only
> interceded to try and frame and consolidated these "loose" discussions into
> a more productive format based on mutual collaboration.  Hence references to
> UML, whiteboards and the need to really think before we type.
>
> But...
>
> Based on your most recent rock-throw I personally would like to see this
> discussion focus on one thing.
>
> What we would like to do.
>
> Personally, I am looking to the Pascal's and Rainwater's for leadership
> here.  I'm only attempting to contribute my time and energies to help push
> the ball along.  I've posted 3 times with queries for "input" and received
> little in the form of response.
>
> One thread asked which of 3 distinctly different endpoint objectives we have
> for this API.  Attached:
>
> (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 will go along way to adding a lot of clarity as to what
> next-steps in this Open Source Forum, based on and proposing to extend
> DynAPI2.
>
> To be honest I was a little disillusioned with the overall response to what
> I was proposing.  And I'm certainly not interested in expending a large
> amount of my time for nothing.
>
> So,...
>
> Lets decide.  I think your negative whiplash reaction was a little
> premature, but knowing the passions of Pascal I understand it.
>
> <emotes> flips blow torch in the air and extends the hand towards the rest
> of you all.
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev