From: Geoffrey F. <fu...@ga...> - 2002-02-07 18:49:07
|
Greetings to all members of the world-wide PLplot development community, Now that we have successfully navigated the 5.1.0 release rapids, I thought it would be an appropriate time to take a step back for a moment, and just do a little group thinking about the future directions for PLplot. We have been with sourceforge for just about two years now. (SF.net shows we registered on 2/23/00, although we were actually with SF.org for about 6 months prior to that), and during this time the project has matured greatly. Breaking the one-person patch incorporation bottleneck was a major enabling factor, and that was followed quickly with the release of PLplot 5.0, which the PLplot user community had been anticipating for probably over 5-7 years. After that we have been doing lots in the areas of bug stomping, configuration, language bindings, driver expansion, and many other things, too many for me to even remember it all. And the project shows every indication of continuing to gather steam as the user base and the developer base grows. Consequently, I have been thinking that it might make sense to put a little more effort into the planning area of the PLplot project, in order to facilitate an orderly and sensibly architected approach to world domination of the explosively growing "scientific plotting software" market segment. :-). To this end, I have been doing a little poking around lately, looking at how other successful and respectable OSS projects are managing their growth and development. The thing I've noticed which has most impressed me, is the use of highly focused topical documents for the purpose of consensus building, software design, and ultimately status reporting. In the Tcl world these are called "TIPs", Tcl Improvement Proposals. In Python they're called "PEPs", Python Enhancement Proposals. In keeping with this, I'd like to propose that we introduce a system of PLplot development centered around "PIPs", PLplot Improvement Proposals. Let me just stop right now, to assure everyone that I have not had some sort of an out-of-body after life experience as a result of a bike wreck or anything like that. I'm not trying to propose in any way that we bog down PLplot development with large bureaucratic systems that stifle developer enthusiasm, or anything like that. We are still small, not anywhere near the size of efforts like the Tcl or Python projects, so I am not imagining some grand massive heavyweight software process here. But, like most OSS projects I am sure, we do have the property that our developers are geographically decentralized. Most of us have never actually exchanged verbal communication with each other or even met in person, and may never (no tears please) so we just need to do what we can in this net-centric environment, to promote orderly development. (Any volunteers to organize (and finance :-) the first world congress of the extended PLplot community? :-) Below, I am presenting a rough draft of a sort of overview of PLplot development activities that I can think of that need to be undertaken. Even while I was composing this over the last week, there have been additional things under discussion on pLplot-devel, and we should probably add to this, things like the palette tool overhaul that Alan is requesting, and probably lots more. I'm sure my compilation, long as it is, under represents the union of the views/ambitions of all developers, so I am by no means trying to squelch anyone. Quite the opposite, I'm trying to catalyze the fleshing out of a real PLplot development agenda. If anyone is not familiar with TIPs or PEPs, I'd encourage taking a little sojourn over to the Tcl and Python projects, and fishing around until you find their TIP and PEP registries, and then just perusing a bit to see how they're organized, what they contain, etc. In very short summary, a PIP should have a clearly identified, highly focused purpose, covering a specific area of (desired) PLplot improvement. And we should realize that PIP's will undergo a sort of life cycle. To begin with, the purpose is stated. Perhaps it will take work on the part of multiple people even to refine that, crystallize it, etc. Ultimately it should document enough background about the current situation in PLplot for someone to really understand what specifically needs to be fixed, improved, or originally developed. Then enough in the way of a design prescription so that a developer can execute it. And finally it should result in a clearly stated result status so that people can know what the end result in the code actually is. This would serve as at least one permanent record of the work, written by the developer, which would provide at least some documentation of what is really going on. I would just like to emphasize again, even though I said above, that I really do not mean to imply that /every/ PLplot development task needs a PIP. People with write access to the cvs are entitled to just keep working their magic, and I hope that continues. But some things are big enough of an undertaking, to warrant some real planning, and review at the planning stage, before proceeding to development, and then of course review of the development before integration. Even in such matters, some tasks are of a character that they can be pursued on cvs head, while others are invasive enough that they really need to be done on a branch, at least at the beginning. The Java binding work is an example which imo, is not really very dangerous, and can proceed on head without much worry about messing anything up. But the dyndriver work was done on a branch until it reached a point that was suitable for integration. So I see that model continuing, where each significant PLplot undertaking utilizes software development strategies and tactics appropriate to its "weight". I guess my main point here is really just that up until now, we have treated almost everything as if it were light weight, with only three things I can think of so far winding up on branches: dydrivers, AM/LT, and TEA (in reverse order). My feeling is that many of the tasks outlined below should wind up on a branch as well. Anything heavy enough to merit a branch, for sure merits a formal PIP. And many things not heavy enough for a branch, still merit a PIP. Finally, one might say that plplot-devel covers the discussion phase adequately. I guess my feeling is that a very large amount of very useful dialog does occur on plplot-devel, but at least for myself, I often feel a few months down the road that I cannot recall some of the important final conclusions on some topic, or even remember the arguments that led to the conclusion in sufficient detail to re-derive the conclusion. Maybe I could be better about archive searching, but I just feel a simpler approach would be to introduce a PIP, where someone (or a multi-person party of responsible someones) usher an actual PIP document through stages of refinement and maturation, so that the current state of the thinking is always available for review in a specific easy to find location. Discussion still would occur on plplot-devel, but the consensus would be actually recorded in the PIP. So, these PIPs, and the PIP registry (PIP #0) would be stored in cvs, say in plplot/pip/pip<#>.txt, or some such. If someone could acquire the TIP management scripts that the Tcl group uses to web-alate their TIPS, that would be great, but even if we just check them into CVS, and /use/ them, personally I would view that as a huge step up from what we do now. Maybe we should store the PIPs in a separate cvs module from the plplot code itself, so that we don't have to worry about PIP's on branches. I dunno, somebody comment on this please. And finally, I'd just like to emphasize that another key point of the PIP notion, is that some of us with extremely limited PLplot hacking time budgets, if we just documented clearly what we think needs to be done, then perhaps we will be better able to recruit additional developers. If newer people can see clearly defined tasks, in writing, they may be able to undertake those development tasks and post patch sets which implement them. In other words, smaller PIPs may serve as a draw for new talent and talent development activities. So, anyway, without further adieu, below follows my first draft of an overview for what I think needs to happen in PLplot. I hope other will comment, both on the whole notion of PIPs described above, and on the specific tasks outlined below. I hope that what comes out of this is an actual consensus on whether people do or don't like the PIP notion (don't be afraid to say nay, if you really don't like it, as discussion forums only work if people really believe they can speak their true mind), and then additional refinement (and expansion?) of the task list. Voila! Complete language bindings: =========================== Java: complete API complete examples Perl: ??? current status ??? What about PDL? C++: Like Java, implement float/double wrappers. Can probably achieve it via member templates, allowing a single method specification for each method. Have to check into that. KCC, use --one_per. What about Intel C++, etc. Python: Revamp plmodule.c, robustify and generalize. E-lisp: Exploit dynamic loadable modules in XEmacs 2X, provide lisp bindings for PLplot API, allowing rendering to embedded buffer widget. Elisp funcs for plotting data in email, or buffers read in from disk, etc. Ruby: ??? Did I miss anything else? Ports: ====== Windows/DOS: Upgrade documentation to clearly describe current options for compiling PLplot on MS-ware. What vendor compilers are currently supported, with what graphics libs? Borland, MS VC? What about djgpp, gcc/cygwin, mingw32? OS/2: emx? gcc? Mac: ? What do we say here ? Other: Anything else? Beos, palm, windows CE? Scientific graphics in the palm of your hand? Does that light anyone's fire? Displace those multi-player palm games for some "real work"? Core work: ========== TEA: Make Tcl and Tk PLplot extensions dynamically loadable via TEA. Make sure that Python/Tk can import plframe dynamically. Driver separation: Introduce "struct PLEnv *", ala JNI, to separate drivers from PLplot core once and for all. Result, all drivers can be linked without reference to libplplot, simplifies dyndriver building, use. Shared libs: Upgrade shared lib support in configure, support Solaris, other notable platforms. Make --enable-dyndrivers default to yes for only those platforms for which we know how to build loadable modules. Note, loadable modules is not the same as shared libs. Could have dyndrivers on a platform without having shared libs, although presumably the additional work to complete shared libs would just be a small additional dribble of effort. X-win/Tk driver dynamification: Don't understand the issues in detail, but something has to be done. Figure it out once and for all, and do it. Plframe Bugs: Of course more is needed than just fixing bugs (see scalable rendering engine below), but still, there are some annoying behaviors of plframe that should be corrected. 1) Plots with large numbers of graphical elements (IC chip layout plots, for example) drop some of the drawings at default/min zoom. They are visible if you zoom in, but then C-r brings you back to the default display, and some lines/polygons are missing. 2) First zoom in seems to often be a double display. Very noticeable for big plots where it takes several seconds in dead time to display. After the first zoom, the screen goes blank, then the plot flashes up, then immediately disappears, then more dead time, followed finally by a redisplay of the image. The second one "sticks". Next zoom is okay. (Still slow, but at least it only redisplays once). But the first zoom down from the top, is a double hitter. 3) C-r does a double redisplay too. Once to go back to the size of the plot when there were scroll bars. But then it notices the scroll bars are gone, so it resizes again and redisplays given the full screen real estate of the fully reseted plframe. Probably we need a way for a Tcl script to set a "don't update" flag in plframe, then it can do the stuff with the Tk geometry manager to resize the plframe sans the scroll bars, then it should reenable event handling and tell plframe to redraw (just once). P-Threaded plframe: Something really needs to be done about plframe's long redisplay times. For plots with lots of graphical elements, the current redisplay code is very painful. Commercial CAD tools, for example, do waaaaay better with zoom/redisplay. The ultimate solution to this problem is almost assuredly some sort of a scalable rendering framework project, such as that outlined below. But it seems that some worthwhile relief could still be obtained in the context of a less ambitious plframe project. Specifically, the redisplay code should be taken out of the parent process thread, and redraw should happen in a separate thread. This display thread should then periodically check for obsolescence of the current tasking orders. So if a 500k vector redisplay is under way (takes many seconds even on fast modern iron), instead of the whole Tk driver being frozen, instead the user would still be able to advance the plot, and the redisplay thread would be notified (via mutex) that the current plot buffer display list was being obsoleted, and it would immediately abandon that and sync up with the new inbound display commands. Similarly, X events that resize the window, unmap it, etc, would all interrupt the display processing thread, so that it could short circuit work that no longer needs to be done. This alone won't solve the issues with the nonscalability of the existing rendering framework, but it would at least provide some relief from the current extreme delays in the current single-thread-with-no-status-polling modus operandi of the redisplay code. Distortion: highly zoomed plots (Tk driver) show obvious coordinate distortion. Believed traceable to 16 bit (short) ints in core->driver interface. Fatten virtual coord rep to 32 bits. Tasks: core->driver dispatch funcs line, polyline, short->int plmeta, dump 4 bytes instead of 2 plrender, bump metafile version, backward handling for old metafiles. dashing: currently walks virtual pixels one-by-one, horrific if expand coord space by 2^16. Need to revamp dashing to /calculate/ (in world coords) dash starts and stops, including bracketing so polyline can turn corners correctly. Tk driver, like plmeta/plrender, bump transmission to use 4 bytes instead of 2. plmeta/plrender: Add page directory. Plrender (w/ mandatory Tk interface? or maybe we call this a new app, named plrendertk?) reads page directory when it inputs metafile, allows page/chapter selection widget for skipping to section introducers, plus telescoping directory expander for page access. Allows random access to plots. Fonts/Stroking: PLplot currently has severely limited textual capabilities. pl[mp]tex allow annotation of the viewport, in viewport-centric terms (character scaling, etc). Consider alternatives: Tasks: Native text: Allow capable devices to draw text with native fonts. This should be supportable for X and PS for sure, maybe more. Learn about native font specification/selection techniques, exploit. Tcl(/Tk) could be a useful guide here (in the done-it-before dept). Text scaling in world coords: There seems to be no way to do this at present, but there should be a way. Note, aspect ratio makes it tricky. There should be a way to perform annotations with text scaled to world coords, and somehow maintain a proper font aspect ratio even if the viewport has extreme aspect ratio. In other words, find a way to specify font scaling in world coords, but make font drawing be font a/r preserving. Tricky, but important. Stroke fonts: Obviously these exist in the code somewhere. Should provide an API for fetching font stroking arrays from the character generator. Then make global PLplot API function for plotting stroke sets. NOTE: a stroke API would be like plline(), but would add an additional indexable field for specifying whether the given coord was a move-to or a draw-to. Other plotting API's I have seen, have had this. Axes (tick label occlusion): I'm sure its much better than it used to be, since we've gotten lots of patch work in the area of plbox and related functions. But still serious deficiencies remain in the area of axis generation and labeling. Issues: Naive use of xtick, nxsub can produce absurdly bogus labeling. I recently produce plots with axis labels evenly spaced:, 1, 2, 4. Also 1, 3, 4, etc. Fractional xtick appears to be ruinous. No easy (and simultaneously reliable) way to control # of axis labels on a side. Extreme aspect ratio plots are a disaster. Axis labels on short axis are all over each other, looks ridiculous. A scientific graphics package should be able to do floor-planning for tick labels! Should calculate non-overlapping windows (in world coords) in which tick labels should reside, then get the labels drawn within these boxes. Requires world-coords lettering capability, mentioned above. Orientation, should be able to write twisted (flowing down) axis labels on X axes. Will be needed when extreme aspect ratio plots are drawn with short axes in X coordinate. zooming (handler, widget) Zooming support in PLplot right now, is present, which is significant by itself. But it could be improved in several ways. Tasks: zoom handler: Currently there is no zoom handler (that I know of), so the zoom support is limited to the widget. Currently the Tk (plframe) widget has zoom support (does the Gnome widget have this too? What about ntk?), but this works by zooming the whole plot, whacking the viewport. An alternative would be to allow installation of a zoom handler. A user-supplied zoom handler could preserve the viewport, but relabel with zoomed box coords, allowing the plot to be accurately redrawn with (side) annotations, but a limited coord range. This capability would be especially useful in situations where there is a plot legend that is obliterated by the current zoom mechanism. Such a mechanism might partially or completely alleviate the damage done by the distortion problem noted above, serving as a poor man's alternative, to a true high quality scalable zooming engine (see below). Geometry aware zoom scalability: The current zoom engine works by replaying the display list with a new window mapping. (Somebody authenticate the accuracy of this statement). But due to the distortion bug (design ramification) mentioned above, the zoomed plots can show serious deformation. Moreover, deep zooms are wasting effort replaying a plot buffer (that was already truncated to 16 bits of usable "mantissa", with the old window mapping) filled with elements that won't be in the viewport. For many types of scientific graphics showing data variation of this versus that, the problem may not be too severe, and modern CPU throughput may handle the situation acceptably. But it is clear that certain application domains have oodles of geometric features in a plot. Think of CAD (circuit layout for the P4, for example), or maybe molecular biophysics and biochemistry (drug design, macro molecules, etc), or even some CFD applications, where there might be 10^9+ graphical elements in a displayed plot. Zooming such a plot will be unbearable with the current zooming framework. (Plus the plot buffer probably doesn't even scale that way, somebody confirm). Need to have a telescoping geometry information database in the display list, so that an intelligent zooming engine can redisplay only those graphics elements with footprint in the new viewport. Quad tree, R-Tree probably others. Widget independence: The above described scalable zooming/rendering engine should be built, but not built directly into plframe. Instead, build this scalable zooming engine in such a way that it can be reused by multiple intelligent widgets. (Tk, Gnome, etc). Annotations, Smart-Visibility, etc.: Related to the scalable zooming engine project proposal above, there is also the issue of feature visibility as a function of zooming factor. Consider the example of CAD, say in particular, the circuit layout for the P4. At the top maybe you see blocks for the ALU, register file, icache, etc. Zoom in by 10^4 and you should be able to see Verilog element names. But the display engine shouldn't waste pixels drawing labels at low magnification, since they'll eat pixels without conveying information. Instead, need an intelligent rendering engine that draws features based on resolvability at the current zoom factor. When the lettering (scaled to world coordinates of small-feature-size graphical elements) becomes large enough to resolve (at extremely high magnification), the lettering is rendered, but not otherwise. Similarly for other feature details. Segments: Other scientific plotting API's (Tektronix Plot 10) have allowed identification of "graphical segments", collections of drawing primitives that together form a single identifiable element. These can then be assigned attributes (brighter, blinking, hidden, etc). Useful in interactive graphics applications. Do we want this? Overlays: At various times over the years, I've wished for an X windows widget that I could pack directly over the top of our current xwin driver. This widget would be transparent in areas not drawn to. This would provide a way to draw atop an image while retaining separation between the image and the annotation. Think of using double buffering where you have an animation (or continuous time computation/display) displaying beneath a fixed labeling/viewport. Consider C++ for PLplot Implementation Language: This has been discussed before, but not seriously for about 3 years. C is painful, just no other way to say it. The above development agenda items (scalable/intelligent rendering framework, multi-stroke "segments", segment attribution) for graphics API core work, will represent significant code authorship activities. Would be /very/ nice to have access to C++ for all that effort. One could advance a powerful (to me) argument for converting the whole PLplot core over to C++. Make drivers derive from an abstract base with pure virtual methods for the driver entry points. Make the PLStream an actual class. Convert the geometric transformation kernels into OO service layers, etc. I could see lots of prospective benefit from this. At the cost of a lot of work that ultimately wouldn't /by itself/ change the core feature set of PLplot. It would be valuable from the standpoint of improving the code structure (to my way of thinking), but wouldn't by itself result in better actual PLplot functionality until subsequent development activity was leveraged on top of it. Consequently, this proposal might be to just start with doing some of these core graphics primitive/API additions, in C++, leaving the existing "plplot core" in C pretty much as it sits right now. Segments could be added in C++, but still ultimately rendered using the existing underlying drawing framework. etc. Have to think a little harder about widget framework extension work though. If we supported a scalable rendering framework effort by authoring code in C++, would we consider revamping plframe into C++ in order to exploit it? Or should we keep widget facilitation infrastructure in C to ease use from existing C widgets? But writing lots of code in C is soooo painful... Something to think hard about. This PIP would have to hit topics like separation of implementation work into subsets for C and C++, composition of the resulting libraries, thinking about linking support with C and FORTRAN codes, impact on dynamic drivers, etc. For example, would wholesale adoption of shared libs allow wholesale migration to C++ without negatively impacting use from C/F77 (including imposing no onerous rules about linking techniques)? Would that alleviate anti-C++ fears? Polygon Intersection: Drawing lines without worrying about occlusion is probably okay. But using plfill to draw polygons can result in situations where one polygon intersects with another. The current code does nothing to handle this. On a pen plotter (HPGL) you can probably see the intersection in the final physical medium, but with raster display devices like X-windows, this info is probably completely lost. Overlays with some sort of translucency might be one way to deal with this. Another way would be to use the geometry feature size aware scalable zooming engine, and endow it with the ability to perform polygon intersection for polygonal elements selected for rendering. Then you'd want some way to chose a color interpolant for the intersection polygon. auto-dependencies: Auto detect GCC 3.0, add makefile magic exploiting -TP and all that. Similar support for other C/C++ compilers, such as KCC, pgiC++, Intel C++, SGI, etc. Identify C++ Compilation Environment: C++ compilers are generally not ABI compatible. This is due to many factors, and has bean purposely promoted by C++ compiler vendors and standards participants over the years. Intel may broker a standardized ABI for C++ on IA-64, but even if successful, it will remain the case that C++ ABI's are incompatible between compiler vendors on other hardware platforms. PLplot should allow compiling libplcxx with multiple compilers, installing to same $prefix, similar to current float/double disambiguation (which is itself extremely valuable in certain circumstances). To do this, append (optional) "environment tag" to name of C++ lib targets, libplcxx_$(env).[a|so]. Improve plplot-config Flexibility: Clients don't always want the same things. plplot-config should recognize some of the same options as provided to configure. Things like --disable-f77, --with-double, etc. So when a client makefile calls $s(shell plplot-config --disable-f77 --libs), what should come back is the current plplot-config --libs output, sans the FORTRAN stubs library, correct precision tag, correct C++ compilation environment tag (see above), etc. plplot-config should support pulling different configurations out of the same prefix, so that sophisticated PLplot client programs can get "just what they want" out of PLplot. Also fix the spurious -Llib eye sore. Contouring: PLplot has long been needing investment in the contouring area. See documented bug relating to Y invariance (or was it X invariance?). Need a robust contouring algorithm. N active view ports: UGS (SLAC), I think also Plot 10 (Tektronix), had multiple active view ports, with independent window mappings. Allowed plots to world coords to appear simultaneously in two view ports, with different coordinate xforms. One really cool application: stereo graphic 3-d molecular structure graphics. Two view ports, with 3 degrees divergence in eye vector, one pass drawing of molecular structure, simultaneous rendering to two side-by-side view ports, and presto, 3-d proteins in your face. Is this something we want in PLplot? Other scientific graphics API's have it. Note, you can do display list replication to multiple view ports the hard way, so it is just a convenience. And there is probably some run time cost associated with supporting N active view ports. But it /is/ convenient for certain situations. Better Data Visualization: surface slices, wall projections, etc. Presentation Graphics: For the executive board room presentation. Bitmaps in the background, all that Power Point glitz stuff. PLplot Applications: ==================== TD/Gnuplot Killer: Its a dirty job, but somebody's gotta do it. We've had this rudimentary plot.tcl thing for several years, but it isn't really up to the task of unseating Gnuplot. (TD was an early interactive data plotting program by Bill Grupp, while he was at Yale/CS. Gnuplot looks to me a lot like the early TD program). This PIP is to build a data plotting /application program/. Probably in Python/Tk, or maybe with one of the other tool kits (gnome/gtk?), that uses PLplot for interactive display and ultimate rendering to printable files. I'm imagining a set of widgets that control data import and field interpretation, resulting in definition of "data sets". Then plotting megawidgets, maybe one for 1-d plots and another for 2-d plots, which control the selection of line styles, markers, colors, etc. This should also be scriptable, so that people can automate production of .epsf files for inclusion in LaTeX docs, etc. Bottom line, some people don't have codes, they have data. And PLplot should serve them too. Browser Plugins: There's a Tcl/Tk Netscape plugin, also a Python Netscape plugin. Can we get a plframe in a Netscape buffer? Can TEA enable plframe to be dynloaded into a page with the Tcl/Tk plugin already activated? Flash Driver: I don't remember the punch line to the former Flash discussions. If this is viable, maybe we need to build a flash driver. Kinda like the plframe loadable into the Tcl/Tk plugin idea above, except that probably more people already have flash. A flash driver might make PLplot a lot more accessible than anything else we have. But this idea needs to be developed more. Explain how we render to it, get it into web pages, etc. Server Loadable Modules (Apache Extension): This is the other end of the browser plugin pipe. Get PLplot into Apache so that plots can be generated without subshells and all that. This idea would have to be fleshed out a lot. Cgi-bin: This is a lot less sophisticated than the server extension PIP, but could still fill a valuable role in promoting PLplot. I wanna go to cnn.com, and find them rendering financials with PLplot. Or big charts.com. Whatever. Anyway, in order to achieve our rightful role as the de facto, world-wide plot rendering engine, we need web serviceability. Learning how to do cgi-bin could be a single, valuable step along this journey. Webserver Plotting Engine: www.sci-plots.org. People point their browser there, post data sets with a web form, get back bitmaps or .epsf they can use. Maybe this would be partially obviated if the Gnuplot Killer App were produced, but my feeling is there will always be people who for one reason or anther, can't run it on their system. They won't have Python installed, can't install, work in an irrepressible Dilbert-phb-dominated company, whatever. Anyway, what these people need is a web site where they can go and get their data plotted, then they take the rendered plot file, and import it into their paper. Documentation, Informative Stuff: ================================= Formalize PIP's (PLplot Improvement Proposals), modeled after TIP's (Tcl IP's). Convert above wish list into families of PIP's. Solicit additional community involvement. The outlined PIPs above constitute 5x to 10x what the current core team can do in 5 years given existing professional obligations. PIP-alizing the PLplot project could encourage SF devfolk to get involved, or might allow corporate sponsorship (or even grants) of PLplot development for existing core team members. Need informative pips, or documentation dev work, to cover many areas of PLplot internals. Current API ref docs and usage chapters are adequate for beginner to intermediate level PLplot app developers. But PLplot hacking itself, needs to be facilitated through substantial documentation effort on PLplot internals. Seeking detailed informative pips on internal coord systems and xformations, clipping behavior, font representation, pattern fill, etc. FAQ: Need to have an online FAQ, with questions that scientists ask. How do I plot a square/circle on the screen? How do I relate world coordinate aspect ratios to the physical medium? How do I implement interactive data querying functions (locator mode)? How to annotate a plot with strings with sizes in word coords? Update website, credits section, acknowledge more people's individual contributions. Testing and Automation: ======================= Current examples are useful as API tutorials. But need more robust API regression test coverage. Framework for automated purify-cation. Continued investment in automated testing framework to reduce human testing load during release process. All these things need to be fleshed out. |