On Apr 24, 2:24 am, Eric Shulman <[email protected]> wrote: > However, regardless of the elegance and technical correctness of any > engineering principles that are applied, these engineering > considerations should be, in my view, secondary to the needs and > interests of the TiddlyWiki end-user/author community. This includes > timely delivery of fixes for known bugs, as well as issues of > reliability, ease/consistency of use, customization, performance, > compatibility and, of course, providing specific feature enhancements > to actually help them achieve their goals.
In my opinion the above could be construed to be a mission statement for TiddlyWiki. TiddlyWiki is a unique framework upon which many applications can be built. Realistically, in the end, it is the applications that are the end product. The original concept of the brilliance of the core has been its attraction to any number of talented developers, coders and application developers alike. The core has lent itself to afford modifications far beyond, I believe, its original intent; in doing so has led it to a unique position of possibly being all things to all people. As technology has progressed more things have become available to actually make this dream a reality, But in fact its limitations of being a single file must be considered if it is to be preserved. This is not to say that the original concept cannot be used as a springboard to even greater things. However I do not believe that TiddlyWiki, as we know it, has come anywhere near completion or obsolescence. I cite Eric's core tweaks (and bug fixes) as an small example of things yet to be included to complete its capabilities without resorting to major changes that might hinder legacy fidelity for things that have gone before. My concern is that the introduction of jQuery (don't think that I don't understand its value for I do) will lead to a long line of changes, bugs and complications that will subject application developers to unnecessary stress and insecurities that may very well lead them to turn to other solutions. On the other hand the introduction of jQuery will be compromised if legacy fidelity must be considered at every turn. If jQuery is to be considered then other advancements (or libraries) like jQuery must also be considered. There must be hooks built in that will allow things yet to be known to be made available to talented coders. If the above is true then there is a case for a separate Super- TiddlyWiki to be considered, one that might not be a single file per say but a basic modern framework that can be built upon to easily become all things to all people while keeping the original TiddlyWiki integrity alive. In summary I believe that the original TiddlyWiki has yet to reach fulfillment, and will not become a cul-de-sac, for it will never become obsolete as long as CSS, HTML and Javascript, and their talented coders with their innovative application developers are alive. There is a case for both if innovation be not stifled and not confused between one another. Morris On Apr 24, 2:24 am, Eric Shulman <[email protected]> wrote: > While writing more automated tests is clearly a reasonable thing to > do, it is only one small part of the decision-making process for > determining which core changes should be made and when they should be > released. In addition to various formal testing paradigms (unit, > regression, integration, platform, and performance/stress tests), > other non-automated, decision-process issues also should be addressed. > > I think that we are really dancing around some practical, as well as > philosophical, differences of opinion related to the overarching > question: > > "Why, when, and how should a given core change be made?" > > Of course, since we are talking about writing code, software > engineering principles -- such as robustness, complexity, ease of > implementation, architecture, and expansion capabilities -- are always > relevant, both for core developers and plugin developers, alike. > > In many instances, a decision can made by a simple comparison of > "costs" vs "benefits" which, while sometimes discussed at length, are > more often glossed over when the benefits seem to be readily apparent, > regardless of value; and the costs, while perhaps not obvious, seem to > be minimal at worst. > > However, regardless of the elegance and technical correctness of any > engineering principles that are applied, these engineering > considerations should be, in my view, secondary to the needs and > interests of the TiddlyWiki end-user/author community. This includes > timely delivery of fixes for known bugs, as well as issues of > reliability, ease/consistency of use, customization, performance, > compatibility and, of course, providing specific feature enhancements > to actually help them achieve their goals. > > thoughts? > > -e --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/TiddlyWikiDev?hl=en -~----------~----~----~----~------~----~------~--~---
