First of all, I would like to see and end to this crap of "going toe to toe" or fighting with each other. This is childish and pointless. There is no reason to stike at each other. I think that we all have a common goal here.
> I thought I did. That you make many changes but there is > little or no discussion in the IRC logs or on the mailing > lists. I'm completely fine with informal discussions, that's > generally how things have been done. You admittedly also have > a "secret agenda" which also doesn't sound like a good thing. Reguardless of agendas, work is being done. Henning is making a great deal of changes to the code base without a great deal of discussion. That much is true. However, as long as he is not making "breaking" changes, I don't really see a problem with it. I for one am very grateful that he is making these changes. They are an improvement on the current code. > > What exactly do you consider "bad"? That I work on a code base that > > you consider dead? > > But that's not where you're heading. You are working in a > direction that is replication of what's in Turbine 3.x. The > Turbine 2.x code is dead but you're doing exactly the same > things I've already done with the 3.x code and after I did > that I realized it was still heavily flawed. So yes, you're > working on the 2.x code base which is, I believe a dead end, > but you are trying to take it to the same place it is already > in 3.x by replicating work and ignoring mechanisms like Avalon. I have not really reviewed the Turbine 3.x code base. I also have not found the time to review plexus/summit to see what you have done to address the design flaws in Turbine. From simply reading discussions in the archives, I understand that Turbine 3 does have some ideas that should be backported. I can't imagine how doing so could be a bad thing. > In the respect that you provide patches and fixes that 2.x > users require I think it's great. In the direction you are > taking the code I think that's bad. As a maintenance effort > superb, as a future endeavor I think dangerous. Having good > and bad aspects simultaneously is not impossible. Then we welcome your discussion on what to avoid. You have been part of this project for a long time. It is also obvious that you are a very talented. Please, start discussing some of the dangers that you see with us on the -dev list. > I'm not trying to relegate your efforts to that of a > 'janitor' as you put it. I just think efforts now would serve > 2.x users to find a way to run 2.x apps inside Summit (which > will run inside Avalon containers other than Plexus) where > there is the pipeline and pluggagle everything. This path > could incorporate any and all code that has been worked on to > date but allow users any path they wish to take in the future > because everything is pluggable. I would love to see Turbine 2.x, Turbine 3.x, Fulcrum, and Plexus/Summit come together into a single project. How much more confusing do we really want to make all of this for people? The Turbine project seems very fragmented for someone evaluating it. We also have a very dire need for documentation. The documentation will be more valuable to the project than Avalonization. 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. Perhaps, it would help if we all steped back and asked what our goals are? Is this project just for the developers who want to write cool code? Is it just an excerise to find the "rigth way" to developer an app framework? Perhaps it is about developing a framework that reduces the development time for a web based application. Every single person that has a production application that is built on top of Turbine has a vested interest in a larger user base. A larger user base helps better ensure the future of the project. It will help attact more developers and contributors. It will cause books to be published. We will start seeing more job postings looking for Turbine experience. 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.... 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. I think that users will be very hesitant to move to a new version of Turbine if the development effort is very high. Upgrading from 2.1 to 2.2 literally scared the hell out of me. 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 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. 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. 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. 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. > 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. > > 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. 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. > > > That you gave up at one point, pulled your code out of the Jakarta > > CVS, because (at least that's what my memory tells me, sorry if I'm > > wrong here) you prefer working on this off-jakarta. Why > didn't you try > > to communicate with the developers who are not present @ irc but > > preferred to move out? > > I certainly had and still have my doubts about Jakarta. I am > far more involved in the under belly and have a far better > understanding of what goes on around here. What I did or > didn't do at this point I feel is irrelevant. What's > important is that I'm going to try and offer something back. > > I definitely think it was a better idea to develop Summit > outside of Jakarta. Turbine 3 took a path I definitely didn't > expect. I worked on it as an experiment, an initial > refactoring of Turbine 2 and I didn't want it used but it was > and I stopped aggressively changing it because there were > people trying to deploy apps. I'm happy that Plexus/Summit > have incubated elsewhere. I don't see a problem with that as > anyone who was interested from Turbine has participated in > Plexus/Summit. We also had two users who became core > developers so I don't see it as a negative thing at all. 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.... > > I (and I think every other Turbine developer but I can't > really speak > > for them) do welcome you, your opinions and ideas on the -dev list. > > But you might understand, even if you don't like it, that we might > > move at a slower pace or even with other ideas than you do. > > That's cool. I will try in that respect to paint a picture of > what I think would be an ideal solution. Something that lets > people work from the application model and building out from > that where different views can be added as components and > concerns like security can be added upon the model and not > intrinsically bound to it. > > I'm not expecting anyone to jump aboard anytime quickly. I > don't mind working at this but I think the let of tools are > finally available to make this happen. > > > And because the developers don't use irc.werken.com to > discuss, this > > doesn't mean that there is no discussion at all. > > 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! > > 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]
