Simon, quick comments. If you are at the stage where you are still open to changing that XML, I'd change: <user> --> <account> <name> --> <username> <passwd> --> <password>
This way there is no confusion between personal name and username, and no "What was the password element again? Was it pass? Or passwd? Or password?" I think your assumption for throwing away old versions and keeping only the latest version is OK. Regarding my understanding of things (points 1. 2. 3. 4.) - was that correct? You didn't comment... Otis ----- Original Message ---- From: Simon Willnauer <[EMAIL PROTECTED]> To: java-dev@lucene.apache.org; Otis Gospodnetic <[EMAIL PROTECTED]> Sent: Saturday, June 10, 2006 11:23:55 AM Subject: Re: create feeds in GDATA - Server 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
