by
dcooper@jade.co.nz >> Wed, 2 Oct 2002 6:46:32 GMT
Wow. This is a passionate thread.
After checking with Craig, it turns out that the presentation he refers to is one I gave in Auckland a few months ago.
My comments in that presentation were in response to a question about the IDE that raised points similar to some of those discussed in this thread. After (hopefully) answering the specific question, I talked about our view of how the *perception* of the IDE has evolved since JADE was launched (ie: I *wasn't* discussing specific NFSs - I certainly don't think IDE NFSs have "dried up" and if I gave that impression, it wasn't intended).
What I mean by "perception" is this. When we launched JADE publicly in 1996, for the next couple of years at least, in nearly all of the technical roadshows/presentations we did to *new* prospects, we could almost rely on issues/objections being raised about the IDE. Very often we always had to bypass this hurdle before we could get to the engine room stuff which is where JADE really brings things to the party. Today, that no longer happens. In the last two years, I cannot remember a presentation to potential new customers where the IDE has been a barrier. And I'm speaking from personal experience here. This year I've done a number of presentations in NZ, Oz and the UK and not once has the IDE been raised as a barrier to someone wanting to go with JADE.
What people want to talk about is stuff like performance/scalability, design (especially for distributed systems, which opens the door to a raft of other things like caching, locking/concurrency, etc), complexity, reusability, language/object model extensions, interoperability, messaging, XML, hardware platforms, operational issues (backup, DR, deployment, hot standby, secondary servers for data warehousing/reporting, etc), Linux, thin client performance, web deployment options... the list goes on. All of these things represent the tough, unglamorous, hard stuff that makes or breaks systems. A number of these are addressed in JADE 6.
So the point I was making in Auckland was that there *has* been a shift in perception/importance of the IDE (either in the market as a whole or because we're now talking to larger/different organisations - probably both). We want to sell more copies of JADE. So when it comes to allocating resource, we need to think about that and listen to what organisations are saying are the hard things. We want to make these things easier. And more often than not today, these things are under the IDE. IDEs have always been fertile ground for religious debate and probably always will be. We must ensure we have a balanced view. Let me state my personal bias and say that if faced with building a significant system, I'd be blissfully happy if my biggest gripe was the IDE - that would be a wonderful problem to have on a large project. Many JADE developers out there feel the same, preferring new/improved core functionality over form. Others will feel strongly about the IDE. Others are in the middle. I think we have all views represented in this discussion
Having said all that, we know the IDE can/should be improved in a number of areas. So let me make a few comments.
1. We are reading this thread. Some good ideas have been discussed and have been noted. I particularly like the idea of editing all methods for a class in a single window and we've had NFSs (both internal and external) for this in the past. This may come along in a planned IDE update *after* JADE 6 (see below). Carl's comments re dockable windows and standardised menus are also good ideas. Both of these are good candidates for the IDE update as well.
2. Early design for the IDE update I mentioned above is already underway. This is taking into account NFSs, comments from discussions like this, as well as things we ourselves want to do. It's scheduled for after JADE 6 as it will contain some significant changes. But it is coming. You may also notice some smaller IDE improvements in the JADE 6 release.
3. The other main point that's been discussed is the provision of an interface to update the meta schema. Regardless of comments that have been made, this is *not* a trivial exercise (especially when you start thinking about things like structural changes to persistent classes with reorg implications, managing the effects of changes in other nodes, etc). I don't intend to debate the technical internals here, you'll just have to take my word for it
However, research is underway on what needs to be done to provide such a layer. This is very early days, so we can't promise anything or say yet what capabilities might be exposed. We fully appreciate that this would be a great facility! It just comes down to priorities. An idea that has been proposed is to provide a way for user applications (in schemas unrelated to those you're working on) to be initiated from the IDE (say via customisable toolbar buttons or menus). This would allow non-updating tools to be initiated from the IDE, much like the monitor can be invoked from the IDE toolbar. We'd be interested in what people think about this.
Dean.