> Great Idea, Fred. I tried only once to register and contribute to a > media wiki, which was tiddlywiki.org. Since this failed I never tried > it again.
I think we're all a bit sad about the barriers to contribution on the mediawiki instance at tiddlywiki.org. And the dissonance between mediawiki and tiddlywiki is awkward. >> > talk about stripping TW to its really essential core, externalizing >> > what's not really essential to external plugins to choose from. It >> > appears just the opposite happening now ? As I say, there's been a lot of discussion over the years about the microkernel approach, I think it has a rather elemental appeal as a concept. But I don't think we've ever committed to that approach; personally, I've never been able to resolve some of the conflicts between the microkernel approach and the existing implementation. My own conclusion is that modularising the core isn't worth it, if the only goal is to enable individuals to omit parts of it. There's a tradeoff between having a stable core that's common to all implementations versus making it easier for a few well informed individuals being able to slice 20% off the core code size. > Thanks for the answer Jeremy. Must have been absent when this policy > change happened. I don't think there's been a policy change, or it doesn't feel like that to me. > Though I do remember the difficulties when the first > tiny bits where removed. Making the DeprecatedFunctionsPlugin > necessary for many plugins which hadn't been maintained since, and > thereby sort of nullifying these efforts again: > http://www.tiddlywiki.com/coreplugins.html#DeprecatedFunctionsPlugin I think this is a different issue, but perhaps they're more related than I perceive. Moving the deprecated functions into their own plugin was a bit of housekeeping to try to clarify the core API by clearly marking interfaces that are really only there for backwards compatibility. >> What we're actually doing is therefore to focus on modularising just >> those bits of code that are generic enough to be used elsewhere. It's >> less about enabling people to trim the core down to a minimum, and >> more about improving the quality of TiddlyWiki's code through more >> people using it. >> > > Does 'modularizing' mean taking bits out of original core and > implementing these - like jQuery.twFile, jQuery.twStylesheet and > jQuery.encoding.digests.sha1.html - as separate modules? Yes, we've been refactoring these modules so that they are practical to use outside of the TiddlyWiki core code. > Or could 'elsewhere' mean this new approach is actually //adding// > plugins - not via a systemConfig tag, but by adding them to the core - > and making the TiddlyWiki core to sort of a code repository to use > with htmls other than TiddlyWikis? I'm not sure if I understand the question. There are certainly now two types of plugins in the tiddlywiki universe: jQuery plugins which are used to encapsulate extensions/enhancements to the JavaScript/HTML/CSS platform, and TiddlyWiki plugins which are used to extend TiddlyWiki itself. It sounds complicated to have two different types of plugin, but they are exposed to completely different people. TiddlyWiki users use TiddlyWiki plugins to extend the platform; jQuery developers may use the TiddlyWiki jQuery plugins to add TiddlyWiki features to other HTML applications. > If this would be the case - which is hard for me to believe - than > TiddlyWiki very soon might shoot up the 1/2 - 1 MB marks, and making > this ever lean again even less possible! > > 1.0.0 Sep 20, 2004 50 KB > 2.0.0 Jan 5, 2006 145 KB > 2.5.2 June 24, 2009 346 KB > 3.0.0 June 2012 ???? KB Yes, TiddlyWiki has got bigger - alongside processors and RAM etc. I've always felt the kilobyte count was a bit misleading; it affects the time to transfer the bytes of TiddlyWiki to a browser. But it turns out in most situations it's actually the execution speed of the code that's the issue, not the loading time. > Though I might have misunderstood you here: Wouldn't it make much more > sense to allow everyone decide - if one wants to be one of those 'more > people' (with which the quality might or might not improve) - by > distributing them using a systemConfig tag as it is done with every > other plugin? The intention is to enable people who are developing non-TiddlyWiki solutions to be able to use these bits of the TiddlyWiki core code. For example, just recently we've had this: http://www.simple-kanban.com/ It's a cool little single-html-page-application. The author expressed a desire to add TiddlyWiki's save routines, but found that it's hard to extract the code and use it independently. It's desirable for that saving code to be more widely used because the more people who are using a bit of code, the more reliable and useful it becomes. So, making, say, the saving code be a systemConfig plugin really wouldn't help that situation.. Best wishes Jeremy > > Regards.. > > > -- Jeremy Ruston mailto:[email protected] http://www.tiddlywiki.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TiddlyWiki" 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/TiddlyWiki?hl=en -~----------~----~----~----~------~----~------~--~---
