|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi guys, Let me give simple inputs for this discussion, but I'm not gonna intervene. ;-) Let me thank all of you, who were very contructive and enthusiastic to improve axis2, the project of all of us. I agree there is still some room for improvements in Axis2, especially in client api and documentations. To tell you the truth, we have allocated next couple of weeks to improve major documentations and client api. During ApacheCon hackathon we did some internal refactorings, as a first step towards this. Documentation : As I always say, this project does not belong only to the developers. As users we want your support as well. I personally thank iksrazal for coming forward and providing us with good documentation whenever required. As Jim mentioned, we developers are not good tech writers (at least me). So if possible, please help us in that. If you can look at axis2 and provide us with feedback, and come up with some good documentation, we really appreciate it. And I personally take the responsibility to publish them, if they are of good quality. Please remember that our aim is to provide what users want with users support. I agree that we can not achieve 100% satisfaction, but we need to satisfy at least a majority of them. Most of the develepors we have in Axis2 have experience in writing more than 4-5 soap stacks. So we believe in their experiences as well. So please help us in improving docs, providing docs in un covered areas, etc., Client API : Todd, if you feel like our client api is not good enough, please come up with a good proposal. We are more than happy to discuss that. Client api is what most users will be working with and these days couple of our guys are working hard to improve it. Here also, please tell us what you want. Regarding XFire and SOAP stacks : Each and every soap stack has its pros and cons. I accept that we need to compete, but we axis2 people are trying our level best to provide the most useful features. We do not have the mind set of providing features, simply XFire or other stack has it. We prioritise the features implementations depending on the user feed back and from our expert's experiences. So in this process, some features which majority of the users feel critical may not be critical for some users, which is unavoidable. So please bear with us. Rememeber one of the motivations behind Axis2 is to implement new technologies related to web services. If some thing is getting delayed, please feel free to come and help us. Let me remind you one last important thing. Personally I feel really comfortable with the features Axis2 provides and Axis2 is not inferior in any means compared to Indigo or any other SOAP stack. So I don't think any one has problems with Axis2 architecture and its features. Criticize us, comment and appreciate us. Whatever it is we appreciate it. Thanks again for all the comments. - -- Chinthaka Jim Azeltine wrote: > This is my third attempt at diving into the use of an open source > product, and on the whole it has been good. I am always impressed > that these individuals will put all the time into these projects, > even though nobody will ever pay them anything for their work. One > thing that I have learned is that it is NOT a good idea to try to > implement a newly released project. I have been paying attention to > the "direction of the breeze" when it comes to Axis 2, but I would > not even consider trying to implement it in a production > environment. It is still too "green" for me. On to the constructive > criticism! 8) (not version specific) > > Rakesh Patel <[EMAIL PROTECTED]> wrote: > >>> I also have not found the experience of working with web >>> services and apache axis a pleasurable one. > > Aside from the frustration factor that is usually present with the > use of open source projects, I find most of the experience > pleasurable. The main source of frustration seems to be related to > the state of the project (how long it has been since release), and > the state of the documentation. > > Rakesh Patel <[EMAIL PROTECTED]> wrote: > >>> The Apache axis docs were pretty bad. Its not geared towards >>> learning the way to use axis, more a reference. I had no idea >>> how to add axis to an existing application. I did it in the end >>> becasue some helpful guy had made available a minimal app that >>> you could use to start from on his blog (why doesn't the main >>> site provide this?). The 1.3 download has docs for 1.2. > > In most cases, an excellent software developer does not make an > excellent documentation writer. I could not agree more with the > statement about the docs not being geared for learning. I would > guess that most of us who are on the hook to deliver a working > project have uttered quite a few "oaths" while trying to solve a > problem using the Axis docs. I find that most of the time, I end up > doing some "creative" googling to try to find an example of > something that works. Trying to figure it out by looking through > the Axis docs is fine some of the time, but not always. For me, if > you give me a working example (not just a disconnected snippet), I > can morph it into what I need. I once was responsible for writing > some training documentation many years ago, and I was told to > "write it so that an 18 year old girl who just got out of high > school will understand it". I was puzzled by this and questioned my > boss, because we had no 18 year old girls in the organization. He > said "But we could, and that is what you have to shoot for. Don't > make any assumptions about what people know. If they do already > know about something, they will skim right over it!". That has > stuck with me all these years, and I always keep it in mind. There > are definately NOT enough examples, and they should be closely > linked (both literally and figuratively) to the docs. Pointing > people to the Architecture Guide does almost no good at all. It is > WAY too high level. The User Guide should be geared towards someone > who knows nothing about Axis, and lead them through from start to > finish on each of the major concepts that need to be understood in > order to effectively use Axis. This needs to include links to ready > to run functional examples that stand by themselves. > > Rakesh Patel <[EMAIL PROTECTED]> wrote: > >>> Overall I'd say that dealing with the underlying servlet code >>> and xml libraries would have been easier to use and easier to >>> understand. I feel that Apache Axis and maybe even web services >>> in general is over-engineered and more compilcated than the >>> alternative implementation (dealing with servlets and xml). > > The main reason I was told to use Axis in the first place was > because of the tools, and that it was supposed to be easy to create > and deploy web services. On the surface, and at the beginning, this > appears to be true, but then you start having difficulties when you > get further down the road. Then you start digging into the docs to > figure things out... If you are prepared for a long ramp-up before > you get to stability (for your own Axis based project), then you > will do ok. If you are not, then it is probably best to buy > something, so you can (hopefully) get support, and resolve your > issues. Even paid support is not perfect. In some cases, open > source list support is better than paid support, if someone knows > about or has dealt with a problem, and you get lucky in that they > read and reply before your deadline looms. 8) > > Rakesh Patel <[EMAIL PROTECTED]> wrote: > >>> Perhaps I'm missing the point. Its when the functionality you >>> need is much more advanced that it pays back the approach. >>> However, if it can't satisfy simple requirements then i think >>> its a failure becuase no-one is going to jump into the >>> complicated stuff when they are first starting out. > > This is so true! That is why Axis appears to be a good choice in > the beginning. But the problem is that unless you are willing to > spend the time to get a really good understanding of SOA, SOAP, and > web services technology, it is almost guaranteed the you will have > a difficult time. > > Srinath Perera wrote: > >>> If it is good architecturally .. we can fix the client API If >>> only you can provide constructive comments. Remember lot of >>> developers has different opinions about it .. some quite >>> opposite. If you comment please be constructive ..random >>> opinions do not help anybody!! > > One of the reason why there are problems getting things fixed in a > support group like this is because people are looking for help, and > may be needing it fast! I recently saw a case where someone posted > an issue in the evening, and said they needed to have it fixed by > morning! This is a stretch. If the right individual just happens to > check, an has the time to come up with a good response, you are > very lucky. In most cases you MUST assume it will take several days > for the solution to get seen by someone and responded to. This > leads to people getting upset, prbably because they need to get the > damn thing working! Under these conditions, it is sometimes > difficult to be civil and constructive. > > > Jim Azeltine Sr. Software Engineer SAIC > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) iD8DBQFDowU+jON2uBzUhh8RAlNqAJ4sSuSiXDuvZ7m7ykVUAV6Jr4telwCgnkmi QYVR7Q0ZyuKxSuFqfT+JHrQ= =i84r -----END PGP SIGNATURE----- |
