Есть идея написать файловый менеджер.
Думаю на чем.

Мотивация:
1 - хочу несколько функций, которых мне не хватает в стандартных менеджерах,
и которые добавить туда слишком сложно. Проще новый написать.

2 - в последнее время - мои походы по собеседованиям и тестовые задания, присылаемые на дом, заставили меня задуматься
о наличии в свободном доступе своих проектов, которые я буду предоставлять в качестве демонстрации своих умений.

И тут, наступают муки выбора языка программирования и среды разработки и архитектуры:
1 - Delphi к сожалению, у меня больше всего опыта работы именно в нем, а он уже никому не нужен
(судя по заработной плате в вакансиях - в среднем около 1.5 - 2 тыс долларов, что примерно в два раза меньше того,
ради чего вообще стоит работать).

2 - С++ тут есть масса вариантов и диалектов - начиная с никому не нужного C++Builder,
(в котором, по понятным причинам, у меня хороший опыт), продолжая странным QT с сомнительными перспективами,
и заканчивая классическими плюсами - либо в MS Visual Studio, либо что-то под линукс на Eclipse / NetBeans и тому подобное.
Опасность плюсов - в безграничности тем и направлений.
Легко можно пойти "не туда, куда надо" и оказаться в результате не востребованным.

3 - Java отпадает по причине личной неприязни к идее JVM, и к ее реализации.
(Как пользователь таких программ, настроен к ним крайне негативно. )
Да - вакансии, да - зарплаты, но все это похоже на какое-то джавабесие, которое должно уже когда-то пройти.

4 - C# честно говоря, просто не знаю зачем вообще нужно писать на шарпе. Чтобы что? В чем смысл?

5 - Теперь очередь в рассмотрении дошла до Web стека.
Да - вакансии, да - зарплаты, да - визы и релокейшен.
Все выглядит круто, хотя и сомнительно, что продержится хотя бы три года такая ситуация.

Итак, если рассматривать применение веб технологий при написании файлового менеджера,
то можно было бы написать сервис на каком-нибудь Node.js
с веб интерфейсом на каком-нибудь ExtJS (Или что там сейчас в моде и круче?).

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

Здесь - смысл написания хорошей программы "для себя" входит в противоречие с желанием "быть в струе"
и иметь интересные предложения работы.
---
Собственно, этими размышлениями и хотелось поделиться.
Вдруг, чей-то свежий взгляд со стороны поможет разобраться во всем этом. :)

А еще остались вопросы выбора базы данных для проекта (SQLite/MySQL/Firebird/MSSQL/Oracle),
и поисковой подсистемы (типа встроенного Elastic Search или Apache Lucene).
И к ним вопросы все те же - баланс между эффективностью и востребованностью на рыке опыта работы с ними.

Сервер БД мне нужен для обьединения информации с нескольких копьютеров и устройств:
планшетов и смартфонов. Предполагается, что он будет хранить списки файлов и каталогов и индексы для быстрого поиска. При этом ФМ сможет отображать и управлять файлами и каталогами не только на устройстве на котором запущен, но и файлами и каталогами на всех компьютерах и устройствах, о которых у него есть информация и есть права доступа.
Быстрый поиск можно реализовать либо индексацией в БД либо внешним поисковым движком.

Базы типа MS SQL и Oracle присутствуют в рассмотрении по нескольким причинам.
Во-первых в случае использования ФМ в корпоративном секторе - наличие таких баз это не проблема.
А для частных лиц всегда есть экспресс-редакции этих баз.
Во-вторых - для примера работ они хорошо подходят, технология пока еще востребована на рынке.
В-третьих - опыта работы с ними у меня много, и его можно использовать и не терять время на изучение.
Это действительно прекрасные инструменты имеющие в своем арсенале какраз то, что нужно - иерархические запросы, хорошо подходящие для работы со структурами типа файловых систем.

В данном случае речь идет о введении дополнительного уровня между данными и пользователем.
Обычная схема выглядит так:
[данные на диске] -> [драйвер] -> [OC API] -> [GUI Application] -> [Человек].
Я добавляю уровень работы с наборами данных:
[данные на диске] -> [драйвер] -> [OC API] -> [ DB SERVICE ] -> [GUI Application] -> [Человек].

Соответственно, клиентское приложение в первую очередь должно быть ориентировано на работу с базой данных.
Все операции сначала проходят через сервер, прежде чем будут переданы на исполнение.
Таким образом, появится возможность отложенных операций.
Например: заказать ожидание какого-то файла - скопировать, когда появится носитель с этим файлом.
Причем, определить наличие файла по его хешу, а не по расположению или имени.
Или частая проблема плохих контактов в картридере - карта отваливается при копировании разветвленного каталога с файлами.
Теперь появится возможность докачки после перетыкания карты.
Ну и различные плюшки типа дедупликации, автоматическое архивирование редко используемых файлов.
История действий с файлами. И много чего еще, что без базы данных в принципе не делается.

Ну какие-такие "облака"? Это смешно.
У меня сейчас дома около 10 терабайт данных на различных включенных устройствах под различными ОС.
Плюс еще столько же на отключенных носителях - дисках и флешках.
И как мне во всем этом быстро найти какой-то файл? Откуда я знаю где он?
А может быть он в каком-то ZIP архиве на отключенном диске? Или на смартфоне в загрузках?
Ну, поищи на выключенных дисках Тоталом. :)

Полный комплект ПО будет включать в себя:
Драйвер ФС - это уж точно на C++ писать

Служба - под линукс - не знаю как, а под винду С++/Delphi/возможно С#?

SQL Server - желательно с развитыми функциями иерархических запросов и такими продвинутыми штуками как FILESTREAM в MS SQL Server

Search Engine - можно попробовать реализовать в БД, или как отдельный сервис на базе чего-то готового.

Web интерфейс - для удаленного доступа к системе (уже писал про Node.js)

Native GUI - под каждую ОС своя. Можно и на шарпе попробовать написать, он вроде и под винду, и под линукс в моно собираться (по слухам должен). Не знаю, не пробовал.

Схема работы этого комплекта такая:
1 - Специальный драйвер файловой системы - используется
2 - службой, поставляющей в базу данных в реальном времени события создания, удаления и изменения файлов, и выполняющей в реальной файловой системе команды, получаемые от сервера БД.
3 - GUI файлового менеджера (Ну хорошо, пусть это будет плагин к вашему любимому Тоталу)
Который отображает файлы, основываясь на данных, получаемых из БД, и отсылающий команды для операций с файлами не напрямую в ОС API, а через сервер БД - службе (см. п. 2), исполняющей реальные действия в файловой системе.

---
Adx,
Вы просто не поняли, поскольку я не раскрыл все подробности проекта.
Но, устраиваясь на работу, не только выбирают меня, но и я так же выбираю - с кем мне работать придется.
Если человек не понимает меня, делает поспешные выводы, то работать мне с ним к сожалению, не получится.
Заметив непонимание, я бы вежливо отказался.