On 6/10/06, Otis Gospodnetic <[EMAIL PROTECTED]> wrote:
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. This sounds good, I can define a xml structure like:
<user> <name>simon</name> <passwd>pw</passwd> </user> to add new users; https will be up to the serverprovider, has to be enabled for defined url! - 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
A new feed can follow the gdata-client api feed structure all I need is available. 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).
This is still not really defined. It does not describe whether the server has to keep the old versions or not. I assue that old versions will be deleted if updated. 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
First i will provied N feeds for 1 User collections can be added as an extension after the SoC Project has finished. 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
Thanks very much for your ideas! simon :) ----- 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]
