Sorry to everyone with a short attention span for this long post. One could also proceed to the last paragraph, to get the gist.
> To be clear, there have been three changes associated with jQuery: > > - the inclusion of the jQuery library by default; this is the decision > that you go on to critique. There was a fair amount of discussion > before we did this; the goal was to enable TiddlyWiki to benefit from > the much higher quality browser compatibility layer in jQuery I read parts of them and I'm very well aware that everyone has put serious consideration before implementing such a big change to the end of bettering TiddlyWiki. You shouldn't misunderstand my posts, that I wouldn't want this to happen. On the contrary, I'm still of the opinion you should go forward with this, and I appreciate you do. Also my arguments for a fork without jQuerry aren't anything you haven't heard already and therefore haven't considered before, nor could I give better ones as those already given by technically more versed contributors before. I just digested all these different perspectives (for example: http://groups.google.co.uk/group/TiddlyWikiDev/browse_thread/thread/c7d270d638383b92# ), multiplied it with the uncertainty factor in life, and salted it with Saq's perspective. And this is what came out of my pondering... I think everyone agrees with the direction of development taken, the advantages of doing so are far too obvious, theoretically. But considering the limited manpower at Osmosoft, these advantages to TW users might become obvious in a few months - or a few years - or, with other uncertainties already talked about, it might make this advantages more obvious to jQuery developers and less obvious to TW users - in the end. That's fine with me this way, and I take the possible risk of never seeing any real advantages. Then I thought - for the many reasons already pondered by others - well, after all it isn't such a big deal, to copy and paste bug fixes into version 2.4.3 and once more get developers on board for a healthy competition, for those who may feel there aren't any opportunities otherwise: > > working at Osmosoft. I don't for a minute believe that there are any > sinister intentions behind this and it has been an unfortunate by- > product of the fact that Jeremy and Martin both work at Osmosoft.. > it's just easier to discuss and develop with those you're in the same > room with. Sadly it means the rest of us don't get an opportunity to > weigh in and contribute. This isn't really meant as criticism, the .. > And once this uncertainty - that there might or might not come betterments to TW end users - has been decided, also the jQuery TW could only profit from it again (without having to take the responsibility to look also for such a kind of legacy TW, beside all the other perceived responsibilities: documentation, tiddly web, cctiddly, cecily, ripple rap, tiddly hub, jquery ...). >From developers, who otherwise may hold back their involvements, because they are simply not sitting in the same room and may wrongly think their forks - if indeed bringing improvements - wouldn't be received well by the community. (if nothing else, these discussions show that there is a real demand for a simple stable TW without an incorporated jQuerry, which at this point is still lacking any perceivable advantage) > > I'm not sure what you mean by the the "code repository for external > jQuery plugin developers". > I mean if an end user needs a piece of functionality he can go to a systemServer, take a tiddler and tag it systemConfig without having to import anything else from this repository. If a jQuerry developer needs a piece of functionality he can come to any TiddlyWiki and use a piece of code - but without the end user having ever decided to distribute code he is ignorant of, nor would know how to use for his own advantage, but costing bandwidth. Sure, also before this was possible with essential functions of TiddlyWiki. But jQuery TW plugins are dependent on jQuery library. And jQuery library dependency wouldn't be necessary for still some time. > > we've done is rearrange the code to make that easier. It sounds like > one of your concerns is that making this functionality into a jQuery > plugin is akin to bloat, which isn't really the case. > At the moment and till above will be decided - in months or years - jQuery library is the bloat. If I upgrade to it without receiving any perceivable advantages yet. > > I'd like to understand more why you think that the integration of > jQuery may be such a big problem. Is it primarily the issue of code > size? > Primarily it is the added size without any perceivable improvement. But I'm aware that this is difficult to understand as a big problem, if you haven't lived for a while in a developing country. However, you don't have too! You can't be responsible for everything - should other developers step up and do it on their own, and for very good reasons independently. Further, the difficulty of former attempts to create a micro kernel. Since this seems to have failed due to the interdependence in the core - why make it now dependent to anything more and that big as the jquery library? - Where to make - or should I say: leave - this ever lean might never become possible again. TW is to communicate, and does this very well and easy to use for newbies via the Internet. I'm aware many developers here would never use it for a website, but this disregard shouldn't lead to the sentiment - because it isn't reasonable for this purpose in their view - TW's size is the least issue to consider. > > The focus has already changed from TW, as now initially and > > necessarily much more efforts has to be given for advancing this new > > kind of jquery plugins, for which only few or no purposes are > > available yet - or already existing the TW way, plus ironing bugs > > which such a refactoring might bring. This is such a great task... > > I'm not sure what you mean here. > Now you're busy with modularizing - converting bits of TW code into jQuery plugins. Consequently done, how long do you reckon this will take? ...That long no real improvement might become perceivable I believe. Conservatively, I guess this will take years. (I'll change my opinion, for example, as soon the new jQuery way of making a saveChanges seriously cuts down the time it takes to save a big TW :-) > > .. I slowly start to see the need for a user only oriented fork again > > - at least for the next 2-3 years. > > I need to understand more about why you think this would be desirable, > and how it would differ from the TiddlyWiki we've got today. Better ask: For an user, does the TiddlyWiki today differ from the one yesterday? Again, there might or might not be any advantages to TW end users at any point in the future. But that long the question remains - why increase bandwidth? There are too many who don't have fast Internet. That doesn't concerns most of us here. But it nevertheless does make it an exclusive thing for the penniless, the majority on this planet. > > there's been a lot of discussion over the years about the > > microkernel approach > > Just to clarify: I don't think it was realistic to expect that end-users > would have to cook their own TiddlyWiki from various modules > While there might be some minor components that might be externalized, > the standard TiddlyWiki distribution should be a stable platform common > to all regular users. It is one thing to realize that the TW kernel is too interwoven for any serious modularization for end users. It is the complete opposite approach then to proceed and create such a heavy dependency as to the 56 bytes weighting compressed jQuery library. > > Someone who wants a more customized version of TiddlyWiki can do so by > using Cook to assemble a version tailored to their needs. (Doing so is > likely to result in incompatibilities with certain plugins.) > I would say TW without jQuerry was very stable and not less complete. So - in an ideal world - it should have been the other way around in my opinion. jQuerry library could have been added with a systemConfig tag by those who need it, for example for TreeviewPlugin. > > > What does everyone think? > But we are not living in an ideal world and the Osmosoft team is clearly overextended, it hasn't been able to set up anything better for end users documentation and communication than this mailing list since many years. Now to expect it would have the resources to leave the existing stable core independent, and optional to include additional jQuerry functionality - as long as this doesn't bring any serious advantages - is just too much to expect, I think. Therefore, though I appreciate your questioning Jeremy, I believe now it is the time for those developers, who may think they haven't got any opportunity to make contribution to the core. There is definitely a demand. > > If people are interested, we could set up another conference call for > a discussion as well, > Thanks for your efforts to create consent. But if there is passion for a slim, stable legacy TiddlyWiki - where jQuery remains optional - developer will step up and your team can concentrate on your task without becoming unnecessarily diverted. I agree with Saq, that if the core remains perceived the sole responsibility of Osmosoft, this very fast could lead to a dangerous situation.. There is no company too big to fail. Best wishes to everyone... --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TiddlyWiki" group. To post to this group, send email to TiddlyWiki@googlegroups.com To unsubscribe from this group, send email to tiddlywiki+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/TiddlyWiki?hl=en -~----------~----~----~----~------~----~------~--~---
