On Wed, Oct 26, 2016 at 4:00 PM, Michal Kozusznik <kozusznik.mic...@ifortuna.cz> wrote: > On 26.10.2016 16:15, Dave Page wrote: >> >> >> Or a misunderstanding on your part on the goals of the project and >> reasons for them. > > > So just list the reasons, please. > IMO there is no single reason to work with files stored on the server. It > could be even considered non-safe in some scenarios. It's enough to work > with client-side files. It's valid for local as well as remote work
Server based deployments, where multiple users manage servers from one or more instances of pgAdmin. >> I agree. Except where it is not possible to do so, or in cases where >> it could lead to an inconsistent UI experience. >> > What do you mean by inconsistent UI experience? If you mean pgadmin having > different file browser appearance across various operating systems then it's > non-relevant argument. Goal should be to have UI-consistent app in > environment it's running under. I mean having to use our own dialogues in some places where native ones cannot work, and native ones in other places. > With client-app responsible for opening files approach, everything would > work out together. Except as I pointed out, we have little control over native dialogues because web browsers have security concerns that cause them to limit access to the client filesystem. -- 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
