lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Otis Gospodnetic <otis_gospodne...@yahoo.com>
Subject Re: create feeds in GDATA - Server
Date Sun, 11 Jun 2006 03:58:55 GMT
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 <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
View raw message