On Thu, Oct 27, 2016 at 11:09 AM, Michal Kozusznik <kozusznik.mic...@ifortuna.cz> wrote: > On 26.10.2016 17:38, Dave Page wrote: >> >> Server based deployments, where multiple users manage servers from one >> or more instances of pgAdmin. > > > After reading your recent responses to various posts I think I'm starting to > understand that the issue lays in the main role pgAdmin4 is designed for. > It seems, you want it to be server administrative tool while pgAdmin3 is not > for sure. > > pgAdmin3 is db design tool more than administration one. Actually it has > nothing to do with administration. Ability to make ad-hoc backups or vacuums > doesn't make it 'administration tool' > It's just GUI extended SQL console. Developers love it just because it's > lightweight, fast and simple. > > What I understood, you want pgAdmin4 to be more administration tool than > design/development tool. It's ok. However in my opinion it's not going to > work this way. Probably it will cover a very subset of administrative > functions which might be useful for beginners. In turn, pro administrators > will still use a console while pgAdmin4 as administration tool will end up > unused. > Let's get backup feature as example. IMO no one will use it in production. > It's because production requires more complex scenarios than execute single > command. Even storing backup files onto server (which server file browsers > are intended to help with) might be bad idea in production. On the other > hand it could be useful for developers but they usually stores backup file > onto local disk. So again: browsing server filesystem is useless. > > Mix of administration and development features wouldn't be bad at all, if it > doesn't negatively affect workflow of users belong to developers/designers > userbase. Unfortunately it's what happens right now: pgAdmin4 is slow and > stripped of some basic OS features as price of being more server oriented. > > I don't know if I'm expressing my self as clear as I want (language > barrier), but as you can see, people rise the same issue again and again. > All of them belongs to the same group: db developers/designers. In my guess > pgAdmin might loose great part of userbase, greater than is able to acquire > thanks to new functionality. Of course you can be OK with it but for sure it > doesn't seem to be win for anybody.
That is simply incorrect. pgAdmin 4 is aimed at exactly the same audience as pgAdmin III - it just takes into account that more and more people want a web based solution - so we aim to cater for both, and in some cases, that means we have to do things in slightly different ways. This was not done on a whim - it was based on all manner of feedback from users, as well as research into industry trends over a number of years. We have put over 15000 hours of development, QA, and doc writing time into pgAdmin 4 and give it away for free. We're well aware there are some rough edges and things that need improving; and fully intend to put effort into doing so. Many of those issues only become apparent when a product starts to be used in the field, and outside of our QA. Ultimately though, we have a new product which frees us from much of the technical debt in pgAdmin III (that caused many of the issues you've complained of in the past that were very difficult to resolve), and allows us the opportunity to vastly improve on what we had before. pgAdmin remains Open Source, and whilst I wish I had another 10 developers to assign to it permanently, I simply don't so some things will not get fixed or changed immediately. As is always the case though, additional contributions are welcome. The best Open Source projects are always the ones with a diverse set of contributors. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgadmin-support mailing list (pgadmin-support@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-support
