On Jul 8, 8:34 am, wolfgang <[email protected]> wrote: > 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..
I swore I would comment no more on this subject on the Developers group. When it comes to this subject it is like talking into the wind. So before I go back to trying to make practical applications for TiddlyWiki I'll just say this. I'm not sure if there are enough worldly wise people here to see the unraveling of a cohesive group taking place. An unraveling that can easily slide into a lowering of moral and dampening enthusiasm for both users and developers. The seeds to this potential unraveling were sown when the decision was made to drastically change the TiddlyWiki core and subject all users to the vagueness of unfinished software on a regular basis for months or years. For the core developers it can be demoralizing because they will feel unappreciated. The fear of bringing an avalanche of criticism with each bug, not to mention breaking favourite plugins, will slow development and quell enthusiasm for them. Users who long for a stable platform to get real-world applications done will balk at every disruption to their progress and the extra uncertainty and distracting discussions that follow. The hard-headed unwavering decision to ignore having a continuing stable platform while continuing with a drastic revamp of the core without having defined separate branches is dangerous. It will create a de facto set of branches anyhow but more importantly it will put users and developers into two separate camps. The argument that users need not follow the the upgrades is a weak one indeed for it actually fosters those de facto branches mentioned above. What choice does that leave users, to go out on a limb that that has been sawed off behind them, or follow the uncertain path development that doesn't really know where it's going. The natural flow of TiddlyWiki being improved and tweaked with each new release will be broken by changing fundamental core functions and if continued will created a separate branch whether you admit it or not. How can any application developer feel their product is reliable enough to be released to the world knowing that the next time their user upgrades the core something might break. The changes to the core using jQuery is a good one, holding great promise. If it is continued as a separate development it will cause no disruption. People will be eager to follow its progress and help with the testing and will be drawn to it through curiosity, and concern they may be left behind, instead of considering it a threat. Whatever extra work separate branches create, whatever extra time it takes is worth it because the real or imagined uncertainties of not doing so will slow its progress even more, or worse divide and lose both developers and users along the way. If I was 'in the same room' as you I would emphatically say this - for it will cost you nothing and you will gain much Take the 2.5.x development out of the backstage upgrade path to foster certainty for users. Continue the jQuery core development with enthusiasm and vigor. Make regular announcements in both groups of new releases. But with one addition. Take the time to also develop little applications as demonstration models for people to try and see some of the advantages. This will give you the testers you need, force you to actually test and document some of the new additions you've made as you go and give people ideas of how they can be used. Then when the time comes to make the switch there will already be enthusiastic users and developers, already knowledgeable and comfortable, to take advantage of it. The time to put version 2.5.x into the backstage upgrade path will occur naturally, you will know with certainty when it is the right time, you will have loyal followers and it may actually be demanded by popular acclaim. That's how separate development paths can actually draw people together instead of one that would divide them. Morris Gray On Jul 8, 8:34 am, wolfgang <[email protected]> wrote: > 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/c... > ), 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 [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 -~----------~----~----~----~------~----~------~--~---
