On Mon, 2003-03-17 at 01:18, Quinton McCombs wrote: > > We also have a very dire need for documentation. The documentation will > be more valuable to the project than Avalonization.
I don't think you really realize how the first portion of your statement will follow without fundamental change. Why do you think there has never been a coherent set of documentation? It's not because of a lack of attempts on the part of many people. > I am in no way > saying that a component based Turbine is not the way to go. I am simply > saying that putting more effort into the documentation will help > increase our user base more than anything else. Well, I disagree strongly. First, we'll see how far this documentation effort goes in reality. Then we'll see what it produces. I've just seen this before and I know what is at the root of inaction when it comes to creating documentation. It stems from the complexity in the core. > Now, how do we increase the user base? Will it happen though making it > easier to migrate to Summit? Will it happen by making Turbine more > component based? Probabley not.... Again I disagree from the vantage of personal experience. Of course users help a project but that won't happen until the internals are coherent. > I think that the best way to > accomplish that goal is by providing help to the user list, improving > the web site, improving the documentation, and making the code even more > stable. > > > There are times when this is good and there are times when > > this isn't. The number of times you will have to deprecate > > across versions is going to be huge. If you want to take that > > path that's fine, in this particular case I think that it > > would be easier in the long run for users to adhere to better > > practices and try to work in a component-based environment. I > > Many of our users are employed by companies to develop applications. > Development time costs money. Making large changes especially > fundamental changes is very dangerous. Which is why the 2.1 application I worked on has not changed all that much. I found it not worth the time or money to spend another second on it and started looking for other avenues to make the process easier. > I think that users will be very > hesitant to move to a new version of Turbine if the development effort > is very high. I'm shooting for as close to zero code changes as possible. > Upgrading from 2.1 to 2.2 literally scared the hell out of me. And so it should, it still amazes me that anyone uses Turbine at all. It's become a tool for adept developers basically and is changed at a fundamental level in a lot of cases to satisfy needs. > I had > deadlines to meet. I had no way of knowing that my update from one > minor version to another would have taken two weeks. How long would it > take to move a fairly complex application using a great deal of the > fucntionality in Turbine to Summit? I'm hoping pretty much zero. At any rate I'm hoping it won't scare the hell out of anybody. > I like the idea of using deprecation. Yes, it will take longer. I want > our users to move to the newer versions of Turbine as they are released. That path is fine. As I said I have no problem with you and Henning doing that. > > I agree that it is in the user's best interests to adhere to better > programming practices. However the way to do this is to present a > roadmap. We will make the changes gradually giving the users time to > adapt. This won't work unless it can be done without a lot of change to the code. Henning has expressed a desire to let things get to the point where 2.3 is release where I will attempt to make a bridge that requires as little code change as possible but allows a 2.3 application to run on an entirely different platform which will provide a much better degree of flexibility where the platform is something that can actually be documented well. And much documentation exists already as people can be pointed to existing Avalon documention and patterns. > Perhaps Summit is the best version of Turbine. If so, I would like to > work towards making our current version more like Summit. > > > think Turbine is highly functional, no one will argue that > > but is flawed in far too many ways to ever be a tool that can > > be learned and extended quickly. My primary concern is not to > > have a tool with a high rate of adoption as that would be a > > natural side effect of having a good body of code and that's > > It takes more than just a good body of code. Most of the users of the > framework do not have your skill level. They will not be as concerened > about the underlying code. I wish they didn't have to be concerned with the underlying code at all. I don't think you're really seeing the point of my endeavour. I would actually like Turbine to be more accessible and not require the huge amount of effort it takes to get an application working. I don't want them to even have to look at the underlying code. > They simply care about it working reliably. > They will also care about having enough documentation to understand how > to use it. Then there is the issue of support. Correct. > > never going to happen with Turbine in it's current form. > > Hasn't happened in last 4 years and it's not going to happen > > without fundamental change. > > If the users are really more interested in better documentation and good > support, then how can you make a statement like this? Turbine is a > great framework. It has it limitations, sure. These are not things > that can not be addressed. Maybe it will take a fundamental change. I > do not think that it has to happen all at once. As I have said before I have gone at this problem before. I am not opposed to any route you and Henning choose to take but at the point of 2.3 I am going to attempt to make a bridge that allows 2.3 applications to run under Summit. > > > That at least some developers try to restore confidence into the > > > Turbine code base; that it will have a future as "Turbine" > > instead of > > > creating half a dozen subprojects with cool names which > > never had any > > > official releases and then got abandoned over night (JCS, Fulcrum, > > > Stratum) or folded at some point into another apache > > project. Do you > > > _honestly_ think that this was "a good thing" to happen to Turbine? > > > > The split should only ever have been used in the Turbine 3.x > > code base. I have said before it was a mistake to have ever > > introduced any of these changes into 2.x. But otherwise, yes > > I think the decoupling of Fulcrum and Torque were a good > > thing. People wanted to use Fulcrum because Scarab was > > driving the development of many of the services that people wanted. > > These were good ideas. I think that they still are. I would like to > release Fulcrum after the avalonization is complete and the changes made > to the coupled services are moved over. > > > Hindsight always provides a better view and in retrospect I > > would have been happy if Turbine 2.x was left alone. It's > > easy to attack what's happened in the past but it's not like > > I had any malicious intent. I was trying to separate the code > > in an attempt to make it available to a wider audience but > > the coupling was too hard to overcome and I started looking > > for other alternatives. > > > > Again, pursue your path. We can create create fully separated > > projects. I don't agree with what you're doing. But we don't > > have to agree. You are free to do what you like as am I. If > > you can convince 2.x users that you've got what they need > > then great, but I'm going to try to do the same. I do feel > > responsible for how I split up the code and left things > > hanging but I honestly didn't have a solution to offer until recently. > > > > Again, I would like for you to give us some ideas for improving the 2.x > code base. You may think that it is dead but you have to think about > what code base the users are on. I have and I do. I not planning on making people rewrite their applications. I'm not a sadist. > Summit is probabley a great product. I had planned on getting involved > in that project but my time has been too constrained lately. It sounds > like you have something working which is technically superior than what > we currently have in Turbine. Perhaps you can help us move Turbine in > the correct direction that would allow both projects to merge into one. I will try. [snip] > > So was part of your reason for developing away from Jakarta to keep > people from trying to deploy it before it was ready? I have been > curious about what you wanted to develop elsewhere. Not that it really > matters.... Just keeping it from sight was something I wanted. Invariably when in CVS you get questions and I was not prepared to answer them before now and I certainly didn't want anyone to try and deploy anything with it unless they were prepared to dig in as a user/developer. Another issue was that I wasn't settled about whether I wanted to stay at Apache at all. Things have been tumultuous between myself and Board but things have settled down now and I'm happier knowing that project automony is of prime concern to the board. > > > > I realize that, but I do follow the mailing lists as well and > > do see much in the way architectural discussion. I'm always > > getting slagged for not providing much in the way of a > > roadmap but I don't see one around here either. At any rate I > > started the Maven roadmap today and will try to do the same > > shortly for what I see as the roadmap for Turbine. > > Perfect. I look forward to seeing more of your ideas! The first attempt of a Maven road map went in and I will attempt the same for Plexus and Summit. > > > Regards > > > Henning > > -- > > jvz. > > > > Jason van Zyl > > [EMAIL PROTECTED] > > http://tambora.zenplex.org > > > > In short, man creates for himself a new religion of a > > rational and technical order to justify his work and to be > > justified in it. > > > > -- Jacques Ellul, The Technological Society > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
