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

[Rafael Fernández López]

On Friday 14 August 2009 11:34:49 David Faure wrote:
> On Friday 14 August 2009, Rafael Fernández López wrote:
> > On Friday 14 August 2009 10:14:53 David Faure wrote:
> > > You can't solve every problem around the house with a hammer,
> > > there are different tools for different purposes.
> >
> > True enough, but I don't think 5 different methods for creating a
> > directory are justified.
> 
> I agree, but I don't see what we can do about that in KDE.
> See my initial reply to the thread; the 3 kde methods have a different
>  purpose, the duplication is between qt and kde, but with a missing feature
>  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.

> > However, in this very case I think KIO, NetAccess and QFile are enough
> > for every purpose. If needed, they can be added flags.
> 
> s/QFile/QDir/ I guess. So we agree up to here, but I don't see any relation
>  with KDE 5.

You have already said it, KStandardDirs. But I also meant KDE 5 in a more wide 
view, not only this issue. Rephrasing "Fix this kind of issues for KDE 5" (not 
only this issue).

About s/QFile/QDir/ yes, I am not only talking about QDir::mkdir, but in 
general filesystem handling. (QFile::copy, QFile::remove...) since (QFile U 
QDir ~ KIO v NetAccess).

> 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.

> > I think I am going to create a techbase page for API users to write this
> > kind of issues, so we can get them fixed for KDE 5. I hope I can have
> > enough time for KDE 5, since this kind of things is one of my
> > priorities...
> 
> For such "small" kde5 todos I'd rather seem then as comments in the code
>  (like we have already in some places) rather than on a separate
>  soon-forgotten techbase page.

As you wish guys, but I some time ago (months?) still have seen comments 
//TODO KDE2. ;) I don't say a techbase page would improve this situation. 
Anyway, better hands to work than being discussing here if a comment on code 
or a techbase page is better.

> > And to sum up following your nice statement, the problem from my POV is
> > when you have different tools for the same purpose (creating a directory,
> > after all) ;)
> 
> Yeah, just like there are different saws, depending on the kind of sawing
> you need to do. Same purpose (cutting wood), but different
>  constraints/goals.

I guess the purpose is the same and we can agree here "creating a directory". 
It doesn't actually matter from the developer point of view if this directory 
is being created in a ftp:// server, or in a local filesystem.

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");
KFoo::makeDir("file:///home/user/myDir");

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.


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/2b5ee809/attachment.sig>