<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
