Re: Development of cross-platform GUI for Open Source DBs

Hi Ritesh,

I'm in support of Tomi's comments (especially those about consulting), and
have a few more thoughts to add. To wit:

First, as an aside, as I didn't know anything about SQLyog, I read your
post first, then went to the URL cited. Throughout your post, it wasn't
clear what the subject was exactly as it seemed you were talking in some
places about a database management interface and in other places some kind
of development environment for people to create cross-platform GUIs in. As
you expand your search for volunteers, you might consider making this more
clear - I'm sure I'm not the only one who doesn't/didn't know what SQLyog
is...

On Sat, 25 Nov 2006, Ritesh Nadhani wrote:
>
> Hello all
>
> Let me introduce myself first. I am the ex-lead developer of SQLyog
> (one of the most popular GUI for MySQL which is Windows only and runs
> on Linux through WINE, more info at http://www.webyog.com)
>
> ===
> New Project: wxWidgets based cross-platform GUI for Open Source databases
> ===
>
> ===
> Motivation
> ===
>
> I have recently shifted to US to study for MS (and hopefully PhD in Univ
> of Iowa). I have also shifted to Mac OS X as my primary usage machine
> (after lifetime of Windows devotion).
>
> As part of my coursework, I work with MySQL and PostgreSQL
> extensively. I searched but couldnt find any GUI which has similar
> power like SQLyog by any means. I have tried (and have tried before
> also) various GUIs for respective databases but somehow the features
> in them are restrictive and are not powerful enough for developers
> like me who writes lots of SQL queries and needs to get things done
> fast.
>
> We can say that we already have enough GUIs for all open source
> databases (open source as well as commercial) available in the market
> but are they powerful enough to suffice the needs of an experienced
> SQL developer as well as newbies. The top three problems with existing
> GUI managers are:
>
> - Most of the usable/powerful GUIs are not open source which is one of
> the most powerful motivation for us to look for an alternate solutions.
>
> - 90% of such GUIs are DB specific. It becomes very hard for developers
> who work with multiple DBs as part of their work. It forces them to
> learn different user interface/softwares to work with the respective
> databases.

A few thoughts here; each db engine has its own;

- sql dialect, dispite the best efforts of SQL92 et al.

- sql query plan output mechanism and format

- naming restrictions (some know from context what table/attribute names
are while others absolutely demand reserved-words remain reserved, even
when they'll never be found in a particular context) - presuming you want
to provide, "works here but not there" advice.

- system catalogs

- index structures

- transaction log semantics

- lock management - presuming you wish to include a "which transaction has
the lock" functionality

- activity/error/security log systems - presuming you wish to provide
error resolution assistance

- maintenance tools suite, like Postgres' vacuum

- backup and recovery suite

>
> - Of the few multiple-db GUIs, 99% (or probably 100%) use JDBC/ODBC
> layer to connect and work with the databases and JAVA or some other kind
> of high level toolkit/language to develop the GUI. This results in
> applications being bulky and slow and never able to provide the speed
> that a low level C/C++ client API provide and are supported by all of
> the standard databases.

The reason - a reason - JDBC (and I presume ODBC) is so popular for these
purposes is that it helps resolve a handful - a large handful - of the
challenges of writing cross-database-platform.

>
> A simple to use GUI for all databases
> ===
>
> The basic idea behind such a GUI is to develop a small footprint,
> extremely fast, multilingual, cross platform administrator/development
> tool for databases. One of the basic requirements thats this GUI will
> fulfill is to allow a developer to efficiently execute/plan queries and
> allow an administrator to quickly do jobs like backups/restores etc.
> with fewest mouse clicks and across different databases.
>
> Once the basic architecture has been set, I plan to extend it to support
> advanced features like MS Access like form development, query builder,
> scheduled backups, data synchronization, configuration management,
> replication manager, user manager etc.

...This is where your stated goals become confusing; What does MS Access
have anything to do with this subject? When you say data synchronization,
do you mean replication - then why mention it separately? (rhetorical
questions)

>
> wxWidgets
> ===
>
> Since last couple of years, wxWidgets (formerly wxWindows) has
> transformed itself into a highly powerful cross-platform GUI library
> which when compiled gives the native look and feel of the host operating
> system. This is something which other libraries like Qt, JAVA lack.
>
> More info about wxwidgets can be found at: http://www.wxwidgets.org.
>
>
> Yet unnamed DB management environment
> ===
>
> I dont have the time nor the resources to do everything by myself. As I
> see, there are too many things which are best distributed among
> people/developers who are good at those specific things. E.g. I will
> require good graphics designer to develop the icons for the tool, web
> developer to keep the website updated, db specific veterans to best code
> individual db management code etc.
>
> Also, it would be a great way to learn some programming and show it as
> part of your undergraduate/graduate project development requirement :)
>
> Is it viable?
> ===
>
> I am not too big a fan of reinventing the wheel or work on a project
> which will go bust in couple of years? So what I want is from you people
> a little initial idea and discussion about such a tool. Is it viable? Is
> it OK to develop such a tool? Will people use it?

Because the distinctive features between RDBMSes I cited above - and
others I didn't cite - change with time, you don't want to hard-code them.
Nor, does it seem to me, do you wish to hard code which database engines
are supported. Therefore, it's clear to me that you want to develop a way
to support any new / new version RDBMS in a way that's easily extensible,
or configurable, if you will. I think it's a lot harder to do than might
sound.

>
> I am cross posting this to various db mailing lists as well as relevant
> newsgroups to get maximum idea about it. You can also contact me
> directly at riteshn(at)gmail(dot)com if you would be interested.

Well, I think we expect you're still on our email list so you can receive
replies, yes? Not everybody replies to both list and author separately.
-shrug-

>
> Waiting for your comments.
>
> -- Ritesh

All that said, I'd use such a tool if one were available...

Richard

--
Richard Troy, Chief Scientist
Science Tools Corporation
510-924-1363 or 202-747-1263
rtroy(at)ScienceTools(dot)com, http://ScienceTools.com/