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
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev
_______________________________________________
Dynapi-Dev mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/dynapi-dev
