The translation layer is what came to my mind about a paragraph before you mentioned it.. howver, you are right that it would be nightmare to porduce and maintain... Plus many, if not most, users of DynAPI tend to make their own modifications to the code for whatever reason.. This I think would make it really quite difficult.
As for porting all the widgets.. I'm all over that. Tho if we are going to do that I'd like to see a documented standard.. (yes, i pulled out the 'S' word again) Nothing too fancy, just a description of the basic structure, and all expected functionality.. maybe revive the style object, or whatnot. It would be nice to see all ported widgets implement the border manager, the existing button objetc, existing form objetcs, etc so that they are more tightly bundled with the API and associated files. Thus an update to the DynAPI border manager that fixes Bug X in browser Y would fix said bug for all widgets that use borders (for example) Or for another example, say we find a more efficient button animation method, then all widgets which use the button-image object would automatically use the new code.. etc, etc... Leif W <[EMAIL PROTECTED]> said: > 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 > > > > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click > _______________________________________________ > Dynapi-Dev mailing list > Dynapi-Dev@lists.sourceforge.net > http://www.mail-archive.com/dynapi-dev@lists.sourceforge.net/ > -- ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ Dynapi-Dev mailing list Dynapi-Dev@lists.sourceforge.net http://www.mail-archive.com/dynapi-dev@lists.sourceforge.net/
