Using Gdata client libs in the server for XML->Java object sounds good. It looks like they use Java 5's XML parser, so you don't need external XML parsers.
Otis ----- Original Message ---- From: Simon Willnauer <[EMAIL PROTECTED]> To: java-dev@lucene.apache.org Sent: Tuesday, May 30, 2006 3:07:05 PM Subject: Re: Gdata Server - Feed / Entry representation No the client lib has no dependency. Using this api will make 5 jars I wanted to use obsolet. I don't need any XML Api anymore. working with the feed (parsing and generating) will be done by the client library. I already started to use it and it fits in perfectly. I will upload a new patch today or tomorrow. You could have a look at it, it's already grown! For a better understanding see the api doc for BaseFeed / BaseEntry classes at http://code.google.com/apis/gdata/javadoc/index.html The api supports also the gdata common elements: http://code.google.com/apis/gdata/common-elements.html I think it's quiet a good idea to reuse the data model of the client lib on the server. simon On 5/30/06, Yonik Seeley <[EMAIL PROTECTED]> wrote: > While the technical benefits remain a bit fuzzy (for me), there is no > reason you wouldn't be able to use them if you needed to since you say > they have an Apache license. Do their client libraries have any other > dependencies? > > -Yonik > http://incubator.apache.org/solr Solr, the open-source Lucene search server > > On 5/30/06, Simon Willnauer <[EMAIL PROTECTED]> wrote: > > See, I have to build an internal representation for an entry or a feed > > inside the server. I have to build these from the incoming entries and > > from the storage to send them back to the client. I also have to > > provide transformation from Atom to RSS. Additionaly Atom allows > > extensions like the google calendar namespace elements. The GData > > client library has a nice API for map these feeds / entries to Objects > > to work with and it does the transformation already. The API is also > > extensible for other ATOM extensions to customize the server for other > > feed "types". So I would use the api to build the representation and > > transfomation. > > The project could also gain some benefit from gdata - api extensions > > in the future. > > > > simon > > > > On 5/30/06, Yonik Seeley <[EMAIL PROTECTED]> wrote: > > > Simon, > > > I just don't quite understand how you are going to use the Google > > > Client API in the GData server. > > > > > > On 5/30/06, Simon Willnauer <[EMAIL PROTECTED]> wrote: > > > > Nobody replies... hmm I assume that this would be ok. Mentors? Doug, > > > > Yonik, Ian? > > > > > > > > simon > > > > > > > > On 5/29/06, Simon Willnauer <[EMAIL PROTECTED]> wrote: > > > > > Hello everyone, > > > > > > > > > > today I reconsidered the internal representation of the feed / > > > > > entries. I had a closer look at the Google Data Client Api which is > > > > > supposed to be the other end to the server. > > > > > This API is dist. under the Apache Licence e.g. open source. It > > > > > already provides the Object representation of feeds and entries. The > > > > > API provides very handy interfaces to extend the protocol and the > > > > > project could benefit from new versions. > > > > > I would rather go for using the api to work with feeds and entries > > > > > inside the server than implement the whole api again. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
