Прежде всего я хочу поблагодарить инженеров Google GData API за их хорошую работу, и я хотел бы отметить, что этот вопрос не предназначен для критики. Это просто указывает на вещи.
Может кто-нибудь объяснить мне это? Насколько я вижу, разработчики клиентской библиотеки Java API Google заново изобретают колесо. Это похоже на написание нового JDK для проекта Java, потому что abdera client делает то, что делает клиентская библиотека google api, а функции и адаптеры abdera server можно использовать также для многих целей, таких как сохранение записей и многие другие.
Мне известно о том факте, что протокол данных Google представляет собой небольшую публикацию отдельных атомов, но если нужно использовать некоторые необычные расширения и функции, предлагаемые проектом Apache Abdera для этого протокола, лучше не использовать Google. клиентская библиотека api и реализация клиента с нуля с помощью Abdera ... И я уверен, что во многих случаях такие функции, как JCR-адаптер Abdera, стали бы очень полезными для документов Google, инструментария Google Translator и практически для большинства других .
Теперь замечательно, что для Google Docs есть клиентская библиотека Google API, но что я собираюсь делать с документами и ответами на атомную ленту? Я считаю, что в более чем половине случаев с другой стороны также есть хранилище или база данных. И в этом случае необходима abdera, а не простые google api-клиенты, которые только сортируют / отменяют сортировку каналов ...
На самом деле во всех API Google есть что-то, что можно сохранить. Это имело бы смысл, если бы Google решил инвестировать усилия в улучшение или интеграцию Abdera ... Это не так ... Особенно, учитывая очень известный факт в разработке программного обеспечения, этот второй выпуск обычно переписывается с нуля. Apache Abdera - это зрелый проект с 5-летним существованием, который используется множеством приложений.
Если есть причины, по которым я не вижу, и реализация клиента с использованием только парсера pull действительно необходима, я бы по крайней мере использовал парсер XML xml, который не считается устаревшим. Xmlpull.org 6 лет, но он неактивен и даже не использует API-интерфейс StAX. Ссылочная реализация stax.codehaus.org, реализация stax JRE по умолчанию, реализация Apache Axiom и, в основном, реализация woodstox.codehaus.org, были бы намного лучше, зачем избегать спецификаций и активных проектов с поддержкой и сообществом?
Я приношу свои извинения разработчикам java-библиотеки google api-клиента за эту критику, но мне очень нравится gis apis, но работа с первой версией этого клиента была по-настоящему горькой, но текущая версия хороша. Но много времени было потрачено впустую, в основном из-за переизобретения колеса и тех крайних изменений между выпусками, начиная с версии 0 через gdata-java-client и заканчивая google-api-client-java.
Наконец, Google ограничивает возможности API после того, как люди вкладывают в это время и деньги, так почему же это важно? : -)
Я возвращаюсь к тому, что сказал, с тех пор программное обеспечение и протокол сильно изменились ... Теперь, когда GData также поддерживает JSON, использовать его даже не имеет смысла!