10 Aug
2013
10 Aug
'13
2:33 p.m.
2013/8/11 Timothy Pearson <kb9vqf(a)pearsoncomputing.net>
You have announced the hard freeze some time ago, doesn't that mean, that
we don't want such changes?
mediaName will stay as I consider it a defect (albiet one out of our
2013/8/11
Timothy Pearson <kb9vqf(a)pearsoncomputing.net
It's steel not perfect:
- mediaName parameter is useless for most of other possible backends, so
it would be nice to pass it as a part of mountOptions map.
- the retcode is assumed to be the pmount's returned code it's better to
return a constant from some enum set.
PS when you introduce the new API, you supposed to mark the old one with
KDE_DEPRECATED rather than just replace it.
or at least please make some announce at list before performing such
changes...
R14 is still in development, so I don't need to use KDE_DEPRECATED. After
release then yes, I would need to do that, hence the urgency of the API
change. :-)
control) if a backend is not able to use a
user-defined mount label.
UDisks 2 nor 1, which IMO are the most wanted backends, are unable to do
that.
Anyway, IMHO it would be better to supply it as a part of the map, because
in that case you'll got one less parameter...
retcode can be changed to an enum without any ABI
problems, so this is not
too high on my list of priorities.
Strictly speaking, this would break the API/ABI unless you'll set some
enumes to specific values. But that not a problem.