Tuesday, May 3, 2011

Ideas for a completely rewritten VoraX 3.0

One year ago the first version of VoraX was released. It initially started as a proof of concept tool but, step by step, evolved into a more complex application. Unfortunately, at that time, my experience in writing Vim plugins was a bit poor. Now, when I'm looking to the code I wrote for implementing several functionalities I don't feel very proud: it's rude, not DRY and hard to maintain/understand. That's one of the reasons I think VoraX 3.0 should be a completely rewritten version. There are also some new features/improvements that I have in mind, the most important ones being:
  • a better DbExplorer tree. The main improvement I see here is the possibility to register custom plugins to provide additional functionality. For example, an user may write a very simple plugin to display DBMS_SPACE statistics for various objects within the tree. The same functionality provided by NERDTree via plugins may be also implemented for DbExplorer.
  • a tree based connection profile window with a XML file behind to store all profiles. I think this would be better than the actual implementation where these profiles are spread out in several files which, of course, is not very intuitive.
  • all VoraX config files should reside in $HOME/.vorax instead of directly in $HOME, messing up the user's home folder.
  • the possibility to configure one output window per tab. Sometimes is useful to open another tab and querying the database from there while preserving the old tab, including the output window.
  • text HTML output. The idea is to display the output of a query in a more friendly format without a lot of "column format" trickery. The main benefit would be that all columns will have the right size. The drawback is that the user must wait for the query to finish and only after that the output will be displayed. That's different than the way it is now when you have immediate feedback and the result is spit out as soon as it is available into the sqlplus out buffer. However, the user should have an easy option to switch from one type of output to another.
  • support for ruby 1.9? I don't know if both versions, 1.8.7 and 1.9 should be supported or not. The problem is that the PTY mechanism used by VoraX for Unix systems has changed in ruby 1.9. As far as Windows platforms are concerned, I must check if win32-api.gem can be used on ruby 1.9. However, being prepared for ruby 1.9 doesn't sound like a bad idea, does it?
  • move to GitHub. I already created a repository for VoraX 3.0. Despite I have little experience with this versioning system I'm eager to learn it because it seems more open to collaboration.
  • completion for various VoraX commands. For example, the :VoraxConnect command may provide completion based on registered connection profiles.
  • new commands. It would be nice to have the possibility to open packages or triggers directly using VoraX commands instead of navigating through the DbExplorer. This may be really handy, especially combined with a smart completion.
  • testing. It would be really nice to have a regression test suite or something in order to validate that the changes made to the code doesn't hurt the current functionality. There are some VIM plugins which may be used to test VimL code but I don't have any experience with any of them. Nevertheless, investing effort in this area would be really helpful.
If you have other ideas (or useful hints) please let me know. VoraX is an open source project therefore everybody is welcome to contribute.

No comments: