[Dynapi-Dev] DynAPI 1 & 2?

[Leif W <war...@us...>]

Hmm, I'm skimming through the recently pinged bug reports and noticed a 
DynAPI 2 question raised by Doug, "Are we patching DynAPI 2 for 
distribution?" (paraphrase).

Short answer is no.  Why?  Because we have a lot of work to do on DynAPI 
3 still.

Long answer?  I think it would be great to consider this for a moment. 
This is just pure speculation at this point.

Should we continue to upgrade DynAPI 2 and DynAPI 1 for that matter, to 
run in the most recent browsers?  I wonder about the feasibility of this 
at the moment and in the future.  Shall we endeavour to maintain three 
targets as opposed to one, when it's all we can do to work on the most 
recent one?  It's not feasible at present with the number of volunteer 
hours we have.  There have been some other parties who have done a bit 
of this work on their own, notably getting DynAPI to run in Gecko 
engines.  But integrating and testing everything, that's a trick.

Am I personally opposed to this?  No.  In the back of my mind I think it 
would be nice to bring the older versions up to dat, if at all possible. 
But, there's so many different browsers, and during each AI incarnation, 
different browsers and version reigned.  It would all have to be recoded 
to split up arch as needed, to avoid dumping it all into single large 
files with a bunch of if/else conditionals.  That would be a nightmare.

In any event, the pipe dream would be to have a drop-in replacement, so 
nothing has to be done to old code.  Hmm, well, yeah, impossible, but 
let's play "what if?".  What if we had some translation layer on top of 
the newest API, so you could optionally bridge the gap between the two 
namespaces (current and whatever the old was).  Likewise, a nightmare 
for maintenance, probably sluggish for performance.  But hey, computers 
are a lot faster now, right?

Hmm, yeah, so then there's also the idea, what if we could provide a 
conversion tool.  Let the end-developer run this tool on their DynAPI 1 
or DynAPI 2 code, and convert it to a DynAPI 3 target.  Nice, but 
probably quite difficult to achieve, when you consider the amalgamation 
of widgets that were never ported or dupliated across all DynAPI 
revisions.  Then you also have to consider that people may prefer DynAPI 
1 or DynAPI 2, so a conversion or translation layer should be able to go 
back and forth any DynAPI version.

So, we come to the final two ideas for ways to handle this.

First, we make a push to port all DynAPI 1 and DynAPI 2 widgets to 
DynAPI 3 platform and techniques.  During this process we make note of 
the steps involved.

Second, we update the documentation based on the notes, so an 
end-developer can understand how to go back and forth.  This provides 
the groundwork for some of the previously mentioned ideas.

These are probably the most realistic things that could be achieved, but 
are still by no means feasible at present.  If we get to the point where 
DynAPI 3 satisfies most people, then maybe we can put new features on 
hold and revisit the ideas to recycle some old code.

Ideas?  Opinions?

Leif