Hi Simon, You asked about several things: - Multiple accounts: Sure. It you have ability to create one account, and you need that to authenticate at the beginning of the session, then why not have the ability to create multiple accounts. I would go for a regular GData/REST interface for account creation (no UI) for now, to make it simple. Something similar to http://code.google.com/apis/gdata/protocol.html#Inserting-a-new-entry , but for accounts. Password would have to be sent in "cleartext", so to make this secure one would have to send this via HTTPS, not HTTP. - Adding new feeds: I would again go for something similar to http://code.google.com/apis/gdata/protocol.html#Inserting-a-new-entry . What is needed for creation of a new feed? Meta-data, right? So send XML POST with feed title, author, and.... what else? Link? For the author perhaps you need the XML representation of a Person object: http://code.google.com/apis/gdata/javadoc/com/google/gdata/data/Person.html Other than the meta-data, what else is needed for a feed? Do you need to ensure that new feed entries that are being added/updated match the a certain schema? For example, do you need to define a feed as allowing foo/bar/baz, but not foo/baz/bar? If you do, themn perhaps feed creation should include taking in a DTD or XSD. This would imply that whenever the client sends you a new feed entry, you'd have to validate it against the DTD or XSD, and either accept it and save it, or reject it with appropriate error code. If this is needed, I would consider simply storing the DTD/XSD along the feed meta-data. I assume that means in your "data store". - Feed entry updates: I think this describes it: http://code.google.com/apis/gdata/protocol.html#Updating-an-entry
Their example: "http://example.com/myFeed/1/2/""myFeed"; looks like a feed ID (a unique name, probably OK to limit to [a-zA-Z0-9]) The first "1" must be the feed entry ID (auto-generated on insert) The second "1" is an incrementing version number. The only bit to pay attention to here is, I think, the version number. The client needs to provide this, but if the provided version number doesn't match what the server has as the latest version, the server should return a 409 (version conflict). Btw., this is how I see different GData entities. Please let me know if any of it is incorrect: 1. A GData server instance has N accounts. 2. An account has N feeds. 3. A feed has fixed meta-data (title, author...) 4. A feed has N feed entries Oh, and I'm wondering whether there should be "An account has N feed collections" and "A feed collection has N feeds" between 1. and 2. Should there be collections? Or is that what "/feed/entry/category/@term" could/should/will be used for? Otis ----- Original Message ---- From: Simon Willnauer To: java-dev@lucene.apache.org Sent: Thursday, June 8, 2006 12:42:31 PM Subject: Re: create feeds in GDATA - Server Do you guys have no suggestions? I would appreciate some suggestions!!! yours simon On 6/6/06, Simon Willnauer wrote: > > The requironments for the U action is just a individual entry update e.g. > an update to an specific existing entry ID like > http://www.yourdomain.com/gdata-server/feedID/someIDb9832a35012704c7bc8cc3326997d9a611f116e7 > > you could also have a look at > http://code.google.com/apis/gdata/protocol.html > > simon > > > On 6/6/06, Chuck Williams wrote: > > > > Simon, > > > > What are your U requirements in the CRUD? Are these only on individual > > items so that delete/add is sufficient, or do you have any bulk update > > requirements? > > > > Chuck > > > > > > Simon Willnauer wrote on 06/06/2006 05:47 AM: > > > Hello, > > > > > > the first version of the GDATA server is already running and it > > > supports all > > > the CRUD actions base on a lucene storage. > > > so the next thing is to enable multiple feed ( I wouldn't be a proper > > > server > > > serving just one single feed instance :). > > > Basically the gdata - protocol description doesn't say anything about > > > inserting new feed instances, the API neither. > > > Lot's of possibilities are around to create an interface for inserting > > > > > new > > > feeds. XML descriptors per feed could be possible but that could > > easily > > > become a xml nightmare. So what else could be provided... There could > > > be a > > > SOAP endpoint for creating/deleteing new Feeds or a secondary REST - > > > Based > > > Interface could be provided. This feeds could be stored inside the > > > storage > > > component including user account data (should we provide more than one > > > user > > > account for altering feeds?!). Quiet easy to use would be a > > > administration > > > JSP based component of the server, but guys don't forget I just have 2 > > > 1/2 > > > month time ;). No problem doing all these extra features when SoC has > > > finished. > > > --> I thought about a mySQL connector for storing entries and > > requesting > > > feeds in addition to the lucene base storage and BerkleyDB as well. > > > > > > regards Simon > > > > > > > > > --------------------------------------------------------------------- > > 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]
