lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Simon Willnauer" <simon.willna...@googlemail.com>
Subject Re: create feeds in GDATA - Server
Date Sun, 11 Jun 2006 09:28:01 GMT
On 6/11/06, Otis Gospodnetic <otis_gospodnetic@yahoo.com> 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 <simon.willnauer@googlemail.com>
> To: java-dev@lucene.apache.org; Otis Gospodnetic <
> otis_gospodnetic@yahoo.com>
> Sent: Saturday, June 10, 2006 11:23:55 AM
> Subject: Re: create feeds in GDATA - Server
>
> On 6/10/06, Otis Gospodnetic <otis_gospodnetic@yahoo.com> 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: java-dev-unsubscribe@lucene.apache.org
> > > > For additional commands, e-mail: java-dev-help@lucene.apache.org
> > > >
> > > >
> > >
> >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> > For additional commands, e-mail: java-dev-help@lucene.apache.org
> >
> >
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message