[Development] Qftp removal
Qt
_______________________________________________
Development mailing list
Devel...@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Richard Moore
> It seems that qftp will be removed in Qt5. I suppose we need to use Qnam instead . But is there a way with qnam to list, mkdir, rename, rmdir ?
No, but if someone wants to implement this then I think people would
be in favour.
Rich.
Qt
Thiago Macieira
> So why remove qftp if there is no complete replacement. I use it in a lot of
> software and it works fine
Because it's old, fragile and unmaintained code. It's really hard to fix bugs
on it, so no one does.
Unlike other working code we marked as Done, this one is really fragile. If
you look at it in a funny way, it will crash. We really don't want people to
use it because they'll run into trouble.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Intel Sweden AB - Registration Number: 556189-6027
Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
David Boosalis
Thiago Macieira
> I've been using it for a year now, have had no problems on Linux and
> Windows. I use it to check for application upgrade. Is there a
> recommended way to do FTP transfers when QFtp is gone. Any chance of QFtp
> getting into Qt Commercial ?
Qt Commercial and Qt Open Source are the same. If it's removed from one, it's
removed from both. We can probably place it in a separate module for people
who still need it.
The recommended way is to use QNetworkAccessManager, which does not have API
for listing directories.
lars....@nokia.com
wrote:
>On Friday, 23 de December de 2011 22.10.19, David Boosalis wrote:
>> I've been using it for a year now, have had no problems on Linux and
>> Windows. I use it to check for application upgrade. Is there a
>> recommended way to do FTP transfers when QFtp is gone. Any chance of
>>QFtp
>> getting into Qt Commercial ?
>
>Qt Commercial and Qt Open Source are the same. If it's removed from one,
>it's
>removed from both. We can probably place it in a separate module for
>people
>who still need it.
Yes, the code is there and while we really need to remove it from
QtNetwork, we should provide a way for people to use it in their projects.
IMO a static lib containing both QHttp and QFtp could be a solution.
Cheers,
Lars
>
>The recommended way is to use QNetworkAccessManager, which does not have
>API
>for listing directories.
>--
>Thiago Macieira - thiago.macieira (AT) intel.com
> Software Architect - Intel Open Source Technology Center
> Intel Sweden AB - Registration Number: 556189-6027
> Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
qtnext
at least test Qt5 on software that use QFtp or QHttp
David Faure
> On Friday, 23 de December de 2011 22.10.19, David Boosalis wrote:
> > I've been using it for a year now, have had no problems on Linux and
> > Windows. I use it to check for application upgrade. Is there a
> > recommended way to do FTP transfers when QFtp is gone. Any chance of QFtp
> > getting into Qt Commercial ?
>
> Qt Commercial and Qt Open Source are the same. If it's removed from one,
> it's removed from both. We can probably place it in a separate module for
> people who still need it.
>
> The recommended way is to use QNetworkAccessManager, which does not have API
> for listing directories.
A solution with Qt5 will be to use KIO, since we (the KDE developers) are
working on making it useable on top of Qt with much less dependencies than in
the current code.
--
David Faure | david...@kdab.com | KDE/Qt Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-independent software solutions
Thiago Macieira
> A solution with Qt5 will be to use KIO, since we (the KDE developers) are
> working on making it useable on top of Qt with much less dependencies than
> in the current code.
And kio_ftp supports a lot more: more commands, better error handling and it
can parse different types of directory listing. It also supports IPv6 -- it was
one of my first contributions back in 2000.
shane....@accenture.com
The rename operation isn't a good fit, because it requires two urls or a hacky custom format to encode source and destination in one url.
________________________________
Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy.
______________________________________________________________________________________
Thiago Macieira
> A directory can be represented by an url, so list, mkdir, rmdir could be
> easily implemented through QNAM's sendCustomRequest The rename operation
> isn't a good fit, because it requires two urls or a hacky custom format to
> encode source and destination in one url.
By the way, these are the KIO operations:
SimpleJob mkdir(KUrl)
SimpleJob rmdir(KUrl)
SimpleJob chmod(KUrl, int)
SimpleJob chown(KUrl, QString, QString)
SimpleJob setModificationTime(KUrl, QDateTime) (POSIX utime)
SimpleJob rename(KUrl, KUrl)
SimpleJob symlink(QString, KUrl)
SimpleJob mount
SimpleJob unmount
StatJob stat(KUrl)
FileJob open(KUrl)
TransferJob get(KUrl)
TransferJob put(KUrl)
TransferJob http_post(KUrl, QByteArray)
TransferJob http_delete(KUrl)
MultiGetJob multi_get(KUrl)
MimetypeJob mimetype(KUrl)
FileCopyJob file_copy(KUrl, KUrl)
FileCopyJob file_move(KUrl, KUrl)
SimpleJob file_delete(KUrl)
ListJob listDir(KUrl)
ListJob listRecursive(KUrl)
SimpleJob special
SimpleJob is a job that simply finishes, there is no data transfer in either
direction. Data-transferring jobs are TransferJob and StoredTransferJob (which
QNetworkReply was based on). StatJob and MimetypeJob are SimpleJobs with a bit
of extra information but I don't know why both exist. ListJob is a like the
TransferJob but it doesn't give you data, it gives you parsed directory
listing.
The FileJob is an interesting one that it allows you to perform seek(), read()
and write() while it's open. It's the only random-access job and the only that
allows interleaved I/O.
The FileCopyJob is an operation that downloads from one server and uploads to
another, then optionally issues a delete command.
shane....@accenture.com
I wouldn't expect a huge amount of commits, but the code (and associated examples/tests) needs to be moved there and converted from dll exports to static libraries.
> -----Original Message-----
> From: development-bounces+shane.kearns=accent...@qt-project.org
> [mailto:development-bounces+shane.kearns=accent...@qt-project.org]
> On Behalf Of lars....@nokia.com
> Sent: Monday, December 26, 2011 10:18
> To: thiago....@intel.com; devel...@qt-project.org
> Subject: Re: [Development] Qftp removal
>
________________________________
Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy.
______________________________________________________________________________________
_______________________________________________
lars....@nokia.com
I people are ok with the name, can you add the repo, Sergio?
Who'd be willing to import the code and examples into that repo? Shane?
Thanks,
Lars
On 1/11/12 3:26 PM, "ext shane....@accenture.com"
Thiago Macieira
> Yes, please. We need a name for it. How about qtnetwork4 ?
>
> I people are ok with the name, can you add the repo, Sergio?
>
> Who'd be willing to import the code and examples into that repo? Shane?
I'd say we should keep each independent class in its own static library build.
So it would be "qftp" inside a kitchen sink repository.
shane....@accenture.com
e.g.
qftp
qhttp
qsettings
"qt4support" isn't a terrible name, unless it has too bad connotations.
"qt4removedapis" is clear as well
I'll take care of moving QHttp and QFtp.
In general, the person removing an API from Qt should add it here for future removals. (assuming it's feasible and desirable to provide the API standalone)
> -----Original Message-----
> From: lars....@nokia.com [mailto:lars....@nokia.com]
> Sent: Wednesday, January 11, 2012 14:49
> To: Kearns, Shane; thiago....@intel.com; devel...@qt-project.org
> Cc: sergio....@nokia.com
> Subject: Re: [Development] Qftp removal
>
shane....@accenture.com
> I'd say we should keep each independent class in its own static library
> build.
> So it would be "qftp" inside a kitchen sink repository.
>
I agree completely
Robin Burchell
> I'd think one project could handle all the removed features we want to support as static libraries
> e.g.
> qftp
> qhttp
> qsettings
>
> "qt4support" isn't a terrible name, unless it has too bad connotations.
I don't really get what's wrong with that name, even with the stigma
of it, because that's exactly what it is. It's a place to put stuff
which isn't wanted in mainstream Qt due to deprecation, but which must
be kept around to help ensure Qt 5's source compatibility promise of
minimal porting effort.
Sure, we might not like the fact that we need a 'support' library, but
if we want to move this stuff, we have to put it somewhere, or break
source compatibility. This is one case where we can't have our cake
and eat it too.
(+1 from me)
shane....@accenture.com
Once there is a project on gerrit, I can push it for code review.
> -----Original Message-----
> From: development-bounces+shane.kearns=accent...@qt-project.org
> [mailto:development-bounces+shane.kearns=accent...@qt-project.org]
> On Behalf Of Thiago Macieira
> Sent: Wednesday, January 11, 2012 15:01
> To: devel...@qt-project.org
> Subject: Re: [Development] Qftp removal
>
________________________________
qtnext
- Kio ? Is there a full Qt port available now ?
- Qft Shane Kearns Module for Qt5?
- available implementation of mkdir, list, in QNAM?
Le 27/12/2011 13:05, Thiago Macieira a écrit :
On Tuesday, 27 de December de 2011 11.02.25, David Faure wrote:A solution with Qt5 will be to use KIO, since we (the KDE developers) are working on making it useable on top of Qt with much less dependencies than in the current code.And kio_ftp supports a lot more: more commands, better error handling and it can parse different types of directory listing. It also supports IPv6 -- it was one of my first contributions back in 2000.
Thiago Macieira
> I need to add now a lot of ftp operations (list, download, upload) in a
> software that is a very good candidate for Qt5 (full Qml). Regarding
> that QFtp will be remove : what is the best option :
> - Kio ? Is there a full Qt port available now ?
What do you mean? KIO is and has always been written on top of Qt.
> - Qft Shane Kearns Module for Qt5?
I don't know where we moved it to. But it should be possible to include this
QFtp module in your application and be happy.
> - available implementation of mkdir, list, in QNAM?
mkdir is easy to add, but not list, since that wouldn't return a standard
QNetworkReply. So no, it's highly unlikely that the full extent of the methods
will be available before Qt 5.2 at the earliest (this is a guess).
Stefan Majewsky
>> - Kio ? Is there a full Qt port available now ?
>
> What do you mean? KIO is and has always been written on top of Qt.
He's probably meaning a "Qt-only port", that is: minimal dependencies
on other KDE libraries. Such a KIO is not available /right now/. The
roadmap says that the split of KIO from kdelibs is going to happen
around May [1], but that's nowhere near a release. I expect that a
modularized KIO, as part of the KDE Development Platform 5.0, will not
become available for general consumption before Q3 2012.
Greetings
Stefan
[1] http://community.kde.org/Frameworks/Epics/Splitting_kdelibs
shane....@accenture.com
As there was no consensus on the repo naming, let's use the original suggestion.
I already ported these classes to two static libraries.
If there are other Qt4 classes that would benefit from this approach, we can rename the repo later.
> -----Original Message-----
> From: lars....@nokia.com [mailto:lars....@nokia.com]
> Sent: 11 January 2012 14:49
> To: Kearns, Shane; thiago....@intel.com; development@qt-
> project.org
> Cc: sergio....@nokia.com
> Subject: Re: [Development] Qftp removal
>
Oswald Buddenhagen
> If there are other Qt4 classes that would benefit from this approach, we can rename the repo later.
>
shane....@accenture.com
Would it be any more complex than creating a new project (initialised with the contents of the previous project repo, rather than empty) and deleting the old project?
And we've created projects with pre-existing git history before, when importing the Qt5 modules to gerrit.
> -----Original Message-----
> From: development-bounces+shane.kearns=accent...@qt-project.org
> [mailto:development-bounces+shane.kearns=accent...@qt-project.org]
> On Behalf Of Oswald Buddenhagen
> Sent: 28 March 2012 17:56
> To: devel...@qt-project.org
> Subject: Re: [Development] Qftp removal
>
________________________________
Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy.
______________________________________________________________________________________
_______________________________________________
Oswald Buddenhagen
> It may not be trivial, but it's the workflow we have defined for promoting a playground module to an official add-on.
>
> Would it be any more complex than creating a new project (initialised
> with the contents of the previous project repo, rather than empty) and
> deleting the old project?
>
deleting projects is not supported, either. every change of structure
will leave a dead repo behind, which clutters up the project overview
(happy admining) and the server.
> And we've created projects with pre-existing git history before, when importing the Qt5 modules to gerrit.
>
that's entirely different. they had no previous gerrit history.
shane....@accenture.com
1. One add-on for each removed API (e.g. qftp.git, qhttp.git)
2. One add-on for each module (e.g. qt4network.git)
3. A catch-all kitchen sink repository (e.g. qt4support.git)
We promised this when removing the APIs, and again in the Qt5 alpha announcement.
The code needs to be available by the time we release the beta.
Each API builds as a separate (static) library using only public exports of Qt5.
(QHttp has a renamed private copy of QAuthenticator and QRingBuffer)
> -----Original Message-----
> From: development-bounces+shane.kearns=accent...@qt-project.org
> [mailto:development-bounces+shane.kearns=accent...@qt-project.org]
> On Behalf Of Oswald Buddenhagen
> Sent: 29 March 2012 16:48
> To: devel...@qt-project.org
> Subject: Re: [Development] Qftp removal
>
________________________________
Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy.
______________________________________________________________________________________
_______________________________________________
Thiago Macieira
> Ok, there are three options I can see and we need to choose one.
>
> 1. One add-on for each removed API (e.g. qftp.git, qhttp.git)
> 2. One add-on for each module (e.g. qt4network.git)
> 3. A catch-all kitchen sink repository (e.g. qt4support.git)
>
> We promised this when removing the APIs, and again in the Qt5 alpha
> announcement. The code needs to be available by the time we release the
> beta.
>
> Each API builds as a separate (static) library using only public exports of
> Qt5. (QHttp has a renamed private copy of QAuthenticator and QRingBuffer)
Go for option 1.
It's not any more effort than the others, unless we decided to build one single
library (which isn't what you said).