API robustness - (was: Different ways to create a directory)

[Rafael Fernández López]

On Friday 14 August 2009 12:04:11 David Faure wrote:
> On Friday 14 August 2009, Rafael Fernández López wrote:
> > >  in the Qt one. So the fix is not KDE5, but adding mode_t to
> > > QDir::mkpath() so that we can get rid of KStandardDirs::makeDir.
> >
> > Yes, that is what I meant. KStandardDirs::makeDir can be removed.
> 
> ... only once you make a Qt merge request that adds mode_t support to
>  QDir::mkpath() (but this can be done today, no need to wait for KDE 5 for
>  that bit. Then we can deprecated KStandardDirs::makeDir and port the code
>  to mkpath, without waiting for kde 5 either.)

I don't see this. The mode parameter can be perfectly added to KIO or 
NetAccess. If we add it to QFile we are limiting ourselves to local 
filesystems. And note that the flag I meant is not the "mode" (the permissions 
given for the new directory) but for completing the path if some directories 
do not exist, that is the particularity of KStandardDirs::makeDir, even more 
than the mode itself.

> > > OK the one thing I see for kde 5 is removing NetAccess since
> > > job->exec() does the same (with the same dangers), but that's not what
> > > you had in mind
> > >
> > >  :)
> >
> > I did not have this in mind since I consider having a synchronous API is
> > also a good idea for certain goals. Obviously NetAccess could be removed,
> > since it is only making what KIO does in a synchronous way, but we would
> > make it harder for developers working synchronously with this API. But I
> > am not in favour of removing NetAccess, for this reason I did not even
> > proposed this option.
> 
> There is nothing hard about calling exec().
> I think you're missing the point that I wanted to make: I agree, a sync api
>  is sometimes useful (in apps that are not complex enough to break on
>  nested event loops...). I'm just saying that instead of the one-line
>  NetAccess::mkdir you can use the two-line KIO::mkdir + job->exec(). That's
>  a great step forward in removing the number of available APIs for doing a
>  given operation, you should be all in favour of it, I would think :)

Yes. But we both know that we would not do it, and we would use NetAccess 
instead because it would not block GUI (using a dangerous event loop, OK, but 
would not block GUI).

You said 2 lines. Yes, 2 lines blocking GUI. If you want to do a synchronous 
call without using NetAccess and without blocking GUI, it is not that easy (2 
lines), and you would repeat dangerous code. That is what I meant.

> > As you wish guys, but I some time ago (months?) still have seen comments
> > //TODO KDE2. ;)
> 
> Can't remember seeing that. But we did go through a lot of "TODO KDE4"
> for kde4, even if not all of them.

It was in KControl... afair.

> > As a develoer, I'd prefer to see some kind of "intelligence" in the API
> > that saves me work, for instance:
> >
> > KFoo::makeDir("ftp://foo:bar@host/myDir");
> 
> 1) nested event loop = dangerous.
> 2) possibly very slow if this FTP site is very slow to answer
> 
> > KFoo::makeDir("file:///home/user/myDir");
> 
> 1) direct calls (if implemented with QDir) = safe.
> 2) should be fast
> 
> => definitely not the same.

Here you absolutely misunderstood me, and supposed I was talking about the 
synchronous API. What I wanted to show is that:

KJob *makeDirRemote = KFoo::makeDir("ftp://foo:bar@host/myDir");
KJob *makeDirLocal = KFoo::makeDir("file:///home/user/myDir");

would be the ideal thing. Since the developer has not to care about what's 
going on behind the scenes. Obviously, the makeDirLocal will execute faster 
than makeDirRemote, but that is something we don't care about.

So the developer can _always_ trust that KFoo::makeDir will do the right 
thing. He can give it a ssh, ftp, file, sftp, ftps protocol, that internally 
it will do whatever is necessary for the operation to succeed.

Internally, KFoo::makeDir could check scheme() for being QString() or "file", 
and in that very case, use QDir internally. I don't see any problem there, and 
would make "one point of contact only" with the outside developer for creating 
a dir.

> > Behind the scenes, it should be done automatically what's needed in order
> > to create that directory, but from an API user perspective this is the
> > best thing, since the API is consistent, and is robust, because it does
> > not matter where the directory is going to be created, the API user
> > _knows_ wherever the directory is going to be created, he can always
> > trust in KFoo::makeDir, because behind the scenes it will take the right
> > decisions in order for the directory be created.
> 
> I'll have to repeat myself again:
> 1) Nested event loops are dangerous (and there is no way to implement
>   makeDir(ftp://) without an event loop currently)
> 2) Synchronous network operations are very bad, they block the GUI for
> an indefinite amount of time.

Yes, but only because you have supposed that I was talking about the 
synchronous API, when I was referring more to the fact of giving different 
protocols to the same method, and it will do the right thing always.

> We have worked hard enough the last 10 years in order to provide a safe and
> asynchronous API for network operations, I don't want to see kde switching
> to blocking calls like KFoo::makeDir("ftp://foo:bar@host/myDir") and random
> apps hanging at random times because some server is slow to answer.
> That would be disaster.

I wasn't referring to this, as I have already explained.


Regards,
Rafael Fernández López.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20090814/f5e76592/attachment.sig>