Как заставить QDirIterator сотрудничать с QFtp?

[niXman]

Дарова!
Можно как-то заставить их сотрудничать? )
Или может есть какаянить альтернатива?

[ритт]

перегрузить QAbstractFileEngine и реализовать в нём "прозрачную" поддержку фтп.
или подождать когда это сделаю я

[niXman]

"или подождать когда это сделаю я" -  Ждать долго то?
Я так и думал что придется перегружать его. Еще думал что возможно как-то это можно сделать иначе...

[ритт]

Я так и думал что придется перегружать его. Еще думал что возможно как-то это можно сделать иначе...

иначе никак.

"или подождать когда это сделаю я" -  Ждать долго то?

ближайшие неделю-полторы времени не будет и я буду недоступен.
назови свои сроки - если нужно срочно, могу помочь с теорией, а потом воспользоваться результатами (пусть даже и неполными); иначе подожди моих результатов и воспользуешься ими сам.
в любом случае, моя реализация будет лучше

[niXman]

в любом случае, моя реализация будет лучше

Как это понимать?!
Думаете уровень моих знаний ниже?

[ритт]

"лучше для меня"

зы. интересно что скрывается под точками)

[ритт]

хорошо, вижу, вызвал негативные эмоции
поэтому поясню: в данный момент асбтрактфайлэнджине подходит для написания вфс-ок лишь по документации. на самом же деле нужно пересматривать реализацию в целом, т.к. текущая реализация достаточна лишь для кутэшного движка - абстрактфайлэнджинеитератор писался на пару лет позже, чем абстрактфайлэнджине - связать их между собой не представляется возможным по причинам бинарной совместимости...и т.д., и т.п. т.е. до 5.0 реализацию никто пересматривать не будет.
сейчас у меня уже есть наработанный набор костылей, есть набор патчей, которые я намерен продвигать в мэйн, вдобавок имеется опыт в написании (в)фс на базе абстрактфайлэнджины.

надеюсь, этих разъяснений достаточно?)

[niXman]

Благо есть над чем поразмыслить...

[ритт]

niXman, предлагаю эксперимент:)

вводные: наша вфс будет иметь предопределённыую структуру пути (урл) - http://ftp://username:userpass@hostname/path/to/somefile. при получении пути, начинающегося с "ftp://", метод QAbstractFileEngine::create(...) создаст нам экземпляр класса FtpFileEngine (назовём его так).
разрешается: пользоваться любыми костылями в меру фантазии.
запрещается: модифицировать классы с префиксом "Q", функции с префиксом "q" и макросы с префиксом "Q_"
требуется: одновременно может быть открыто более одного фтп-соединения (сессии), но фактическое соединение для каждой сессии должно быть уникальным - т.е., для любой отдельной сессии перечисление каталога (FtpFileEngineIterator) и файловые операции (FtpFileEngine) должны происходить с использованием одного и того же экземпляра класса QFtp - без разрыва соединения между операциями. при завершении работы с сессией соединение должно быть разорвано и отпущены использованные ресурсы (внешних признаков окончания сессии нет - вероятно, их потребуется определить по использованию ресурсов).

какие будут идеи?

[niXman]

Увлекательное предложение.
Но дело в том, что у меня сейчас проект, и мне не нужна такая "крутая" реализация.
Вы недели-полторы будите заняты? Постараюсь к этому времени освободиться.

P.S.
Предложение принято.

[ритт]

к сожалению, задачка с фтпфс более простая, чем задачка с зипфс, которой я сейчас мучаюсь. наверное, есть какой-то обходной способ упростить мои мучения, но для этого мне нужен свежий взгляд и пинок под зад
сегодня услышал мнение, что QAbstractFileEngine уже не покрывает потребности нативной QFSFIleEngine. но сделать с этим до 5.0 они всё-равно ничего не могут (помним про source compatibility?)
прискорбно, конечно, но выбора нет - костыли и патчи...

зы. не нужно на "вы" - мы же здесь в одном котле

[niXman]

наверное, есть какой-то обходной способ упростить мои мучения

Есть же много готовых реализаций. Даже, где видел STL compatible.

сегодня услышал мнение, что QAbstractFileEngine уже не покрывает потребности нативной QFSFIleEngine

А в чем причина?

помним про source compatibility?

Да.

не нужно на "вы" - мы же здесь в одном котле

Ок.

[ритт]

наверное, есть какой-то обходной способ упростить мои мучения

Есть же много готовых реализаций. Даже, где видел STL compatible.

готовые не подойдут, т.к. перестраивать интерфейс нельзя. а писать свой набор контейнеров и моделей - тоже не вариант.

сегодня услышал мнение, что QAbstractFileEngine уже не покрывает потребности нативной QFSFIleEngine

А в чем причина?

причина не называлась, но по косвенным признакам могу сделать предположение, что какие-то новые идеи также приходится реализовывать через костыли (мап/анмап, например)

моя задача - сделать фвс, прозрачную для приложения (в идеале любого на кутэ). т.е. в моём случае QFile("file.zip") - это файл, но QDir("file.zip") - это папка. это победил уже - написал пару патчей. но проблема в том, что без контекста невозможно определить что же требуется от пути: QFileInfo("file.zip") - это файл или папка? сейчас это файл и сделать его папкой можно лишь так: QFileInfo("file.zip/"), но тогда файлинфо будет возвращать другие filePath() и т.п., чем QFileInfo("file.zip")...
буду всю поездку ломать над этим голову...надеюсь, что-нибудь придумается

[niXman]

По реализации ВФС опыт имеется(не большой). Думаю что ЗИП ФС, было бы проще реализовать на Кутэ, а не в Кутэ(мне так кажеться).

[ритт]

zipfs я уже реализовал через ZipFileEngine (пока только на чтение). вот только хочется "прозраности"...
но я в принципе согласен - если за время поездки ничего умного не придумается, придётся отказаться от "прозрачности" и сделать что-нть вроде регистрации расширений для различных вфс (.zip, .iso и т.п.). это создаст массу неудобств и боюсь, придётся тогда клепать какие-нибудь промежуточные костыли для прозрачности файловых операций