On 6/11/06, Otis Gospodnetic <[EMAIL PROTECTED]> wrote:
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>
I do agree with you, this was just an example. For the final schema I will discuss that on the mailiing list again.
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...
These points are correct! simon 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]
