Могу выложить, но парсер/генератор писались сугубо под себя и сугубо под мою задачу. Если парсер Thirft еще можно приспособить, то генератор кода заметно нужно будет менять. А комментариев там нет как класс.
Эксперимент есть эксперимент. Наверное, попробую сделать асинхронный вариант API. Я правда пока сомневаюсь, что сам я найду ему применение, но, может, кому-то и пригодится. Время покажет.
Хотелось много чего сказать, но я ограничусь одним тезисом: полезно читать перед тем как писать.
Прочитайте еще раз мою заметку, гляньте исходники QEverCloud. Надеюсь, вам станет понятно, что целью QEverCloud является заменить предлагаемые Evernote сгенеренные thrift компилятором файлы, которые громко именуются Evernote SDK for C++, а не написать конкретную прикладную программу.
В рамках этой цели предлагаемые вам исходники не представляют интереса — там этот самый Evernote SDK for C++ во всю используется, а не заменяется.
Все дальнейшее в программе по поводу Evernote мало интересно с точки зрения общего SDK, предназначенного для любых программ с самыми разнообразными задачами и архитектурой. QAbstractItemModel в качестве API к Evernote? Даже не смешно. Как решение задач конкретной программы — почему бы и нет, но как SDK к Evernote (а именно это есть тема заметки) — идея явно не очень здравая.
Более того, ваш глубокомысленный тезис о «другие пользователи опередили» имеет неявный подтекст, что предлагаемый мною подход к написанию программ — многопоточность с вынесением обращений к Evernote в отдельные потоки — неверен. Что явно говорит о том, что вы не потрудились ознакомится с темой, перед тем как писать. Ибо в приведенных вами исходниках используется именно этот подход, против которого EuroElessar привел массу разумных и интересных контраргументов, пусть с ними и можно поспорить. Вы уж определитесь, что вы хотите сказать.
Так что я ваш тезис о хороших идеях как-то не понял. В приведенных вами исходниках я их не нашел ничего нового и особого интересного.
Если вам хочется конструктивной дискуссии — пожалуйста, конкретику в студию. Какие хорошие с вашей точки зрения идеи вы хотели бы видеть в QEverCloud, но не видите? Или может вы хотели бы реализовать хорошую идею с помощью QEverCloud, но не можете из-за каких-то ограничений библиотеки?
Как общаться с тем потоком из гуя? Все равно придется городить асинхронное API, т.е. опять приходим к начальной проблеме
Зато на более высоком уровне, более соответствующем логике конкретной программы. Я не назвал бы это изначальной проблемой. К тому же, общение между потоками в Qt не есть большая проблема. Все готово, сигналы/слоты между потоками работают.
Многопоточность — это накладные расходы, лишняя память, лишние context switch'и. Асинхронное API, основанное на event loop почти всегда быстрее.
Это верно, но, насколько я понимаю, по сравнению с затратами на сетевые вещи все эти расходы теряют значимость.
«Я не понимаю никакого бонуса выноса синхронных методов в отдельный поток, с точки зрения API будет хуже, чем event loop-based API, писать сложнее, использовать тоже сложнее.»
Это субъективно. Моему субъекту, например, все кажется прямо наоборот.
Вашему примеру для полноты картины не хватает последовательности вызовов Evernote. В качестве гипотетического случая: три раза createNote, строго один за другим. В синхронном API это выглядит проще некуда:
«Вообще мне кажется плохим тоном инициализировать qsrand из библиотеки — этим должно заниматься приложение.»
В принципе, я согласен. Лезть исподтишка библиотекой в глобальное состояние — оно действительно некрасиво. Но в данном случае, имхо, это не то чтобы совсем страшно. Если программист вызовет qsrand() где-нибудь в main, то мои закулисые манипуляции потеряют эффект, а если нет — то ему, по видимому, все равно, qrand/rand он не использует и я ему не мешаю.
Гораздо неприятнее будет, если программист забудет вызвать qsrand() и в таком виде отдаст свою программу пользователям. Дыра в безопасности, которую моя библиотека некрасивыми средствами пытается закрыть.
Я думал об этом, но пришел к выводу, что в случае с Thrift вообще и Evernote в частности такая модель не стоит того гембеля, что она привносит. Согласитесь, асинхронность превратит код в лапшу.
Thrift по своей идеологии имитирует вызов локальных функций, и Evernote этой идеологии всецело придерживается. Почти всегда перед тем, как выполнять следующий запрос к Evernote, нужно знать результат предыдущего. Как следствие, основное преимущество асинхронной модели — параллелизируемость на уровне отдельных запросов — сводится практически на нет.
Имхо проще и в целом так же эффективно будет реализовывать логически связанные последовательности запросов (как то же создание заметки) в виде синхронных вызовов, выполняемых в отдельном потоке. Тогда отдельные последовательности параллелизируются, код удобочитаем, и интерфейс = главный поток «замирать» не будет.
Если народ захочет асинхронности, то можно и сделать… но я пока не ощутил в ней насущной необходимости.
«Заморозку» интерфейса можно решить многопоточностью. Распараллеливание на уровне отдельных обращений к Evernote таким образом не получится, но оно по логике самого API в целом неосуществимо.
Хм… Видимо, Evernote в принципе не предназначен для реальных сложных проектов. Все SDK им предлагаемые — синхронные.
Кстати, если серьезно: ничто не мешает мне сделать асинхронный вариант API, немного поменяв генератор кода. Единственный вопрос: как оно, это асинхронное API, дожно выглядеть? У вас похоже, есть ответ на этот вопрос. Не поделитесь ответом?
Пример использования на GitHub.
Могу выложить, но парсер/генератор писались сугубо под себя и сугубо под мою задачу. Если парсер Thirft еще можно приспособить, то генератор кода заметно нужно будет менять. А комментариев там нет как класс.
Прочитайте еще раз мою заметку, гляньте исходники QEverCloud. Надеюсь, вам станет понятно, что целью QEverCloud является заменить предлагаемые Evernote сгенеренные thrift компилятором файлы, которые громко именуются Evernote SDK for C++, а не написать конкретную прикладную программу.
В рамках этой цели предлагаемые вам исходники не представляют интереса — там этот самый Evernote SDK for C++ во всю используется, а не заменяется.
Все дальнейшее в программе по поводу Evernote мало интересно с точки зрения общего SDK, предназначенного для любых программ с самыми разнообразными задачами и архитектурой. QAbstractItemModel в качестве API к Evernote? Даже не смешно. Как решение задач конкретной программы — почему бы и нет, но как SDK к Evernote (а именно это есть тема заметки) — идея явно не очень здравая.
Более того, ваш глубокомысленный тезис о «другие пользователи опередили» имеет неявный подтекст, что предлагаемый мною подход к написанию программ — многопоточность с вынесением обращений к Evernote в отдельные потоки — неверен. Что явно говорит о том, что вы не потрудились ознакомится с темой, перед тем как писать. Ибо в приведенных вами исходниках используется именно этот подход, против которого EuroElessar привел массу разумных и интересных контраргументов, пусть с ними и можно поспорить. Вы уж определитесь, что вы хотите сказать.
Так что я ваш тезис о хороших идеях как-то не понял. В приведенных вами исходниках я их не нашел ничего нового и особого интересного.
Если вам хочется конструктивной дискуссии — пожалуйста, конкретику в студию. Какие хорошие с вашей точки зрения идеи вы хотели бы видеть в QEverCloud, но не видите? Или может вы хотели бы реализовать хорошую идею с помощью QEverCloud, но не можете из-за каких-то ограничений библиотеки?
Увы, но MSVC2010 все еще бывает актуальным. И когда уже оно подохнет…
Зато на более высоком уровне, более соответствующем логике конкретной программы. Я не назвал бы это изначальной проблемой. К тому же, общение между потоками в Qt не есть большая проблема. Все готово, сигналы/слоты между потоками работают.
Это верно, но, насколько я понимаю, по сравнению с затратами на сетевые вещи все эти расходы теряют значимость.
Это субъективно. Моему субъекту, например, все кажется прямо наоборот.
Вашему примеру для полноты картины не хватает последовательности вызовов Evernote. В качестве гипотетического случая: три раза createNote, строго один за другим. В синхронном API это выглядит проще некуда:
А в асинхронном?
В принципе, я согласен. Лезть исподтишка библиотекой в глобальное состояние — оно действительно некрасиво. Но в данном случае, имхо, это не то чтобы совсем страшно. Если программист вызовет qsrand() где-нибудь в main, то мои закулисые манипуляции потеряют эффект, а если нет — то ему, по видимому, все равно, qrand/rand он не использует и я ему не мешаю.
Гораздо неприятнее будет, если программист забудет вызвать qsrand() и в таком виде отдаст свою программу пользователям. Дыра в безопасности, которую моя библиотека некрасивыми средствами пытается закрыть.
Thrift по своей идеологии имитирует вызов локальных функций, и Evernote этой идеологии всецело придерживается. Почти всегда перед тем, как выполнять следующий запрос к Evernote, нужно знать результат предыдущего. Как следствие, основное преимущество асинхронной модели — параллелизируемость на уровне отдельных запросов — сводится практически на нет.
Имхо проще и в целом так же эффективно будет реализовывать логически связанные последовательности запросов (как то же создание заметки) в виде синхронных вызовов, выполняемых в отдельном потоке. Тогда отдельные последовательности параллелизируются, код удобочитаем, и интерфейс = главный поток «замирать» не будет.
Если народ захочет асинхронности, то можно и сделать… но я пока не ощутил в ней насущной необходимости.
«Сейчас все адекватные компиляторы уже умеют c++11 в достаточной степени» — это если не поминать MSVC незлым тихим словом.
QDialog::open — да, забыл про него. Видимо потому, что никогда не использую :)
Пофиксю при случае.
По поводу «256 возможных значений» не понял. Можете ткнуть носом в конкретную строку? Я такого бага не вижу.
std::mt19937_64 — это, если я не ошибаюсь, c++11. Библиотека под c++03.
Пожалуй, надо бы фанктор прикрутить в параметры authenticate для генерации nonce.
Кстати, если серьезно: ничто не мешает мне сделать асинхронный вариант API, немного поменяв генератор кода. Единственный вопрос: как оно, это асинхронное API, дожно выглядеть? У вас похоже, есть ответ на этот вопрос. Не поделитесь ответом?
Чтобы даты заметки были одинаковыми я бы просто задавал created и updated при создании заметки. В QEverCloud это бы выглядело где-то так:
quint64 time = QDateTime::currentMSecsSinceEpoch();
Note note;
note.created = time;
note.updated = time;
note.title =…
note.content =…
noteStote->createNote(note);
Как это в Java API будет и какие там еще баги подстерегают — этого я уже не скажу…