[rfk-dev] androidfindskitten

[Steve Pomeroy]

On Thu, Jun 04, 2009 at 02:02:54PM +0200, Lajcik wrote:
> An update mechanism is definitely better than fetching a whole blob each
> time there's an update.

Why? This isn't a lot of data. Sure it could be more efficient, but
there are benefits to simplicity when it comes to implementing a
consumer.

Debian, for example, has a package index which is just a gzipped list.
By default, it would just transmit every time and use some HTTP
if-modified-since goodness to determine if the client needs to update or
not. Recently, as the number of changes has gone up (nowhere near what
we're talking), they decided that they needed to implement an
incremental update mechanism.

My solution:

Just serve a JSON file which contains all the NKI. It should be as
simple as:

   [ 'nki1', 'nki2']

Use HTTP if-modified-since negotiation to determine if a client needs to
be sent the whole thing or just told that it hasn't been updated.
Handily, Apache and other webservers do this for all their flat files,
so you could just have the DB write to a file when it gets updated (or
implement the same header handling in your NKI server).

see: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.25

I'd be very happy to just be able to do:

    curl http://rfk.example.org/nki/NKI_PACKAGE

and be returned a JSON list of NKI from package NKI_PACKAGE.

A smart client could store the last time it updated its NKI and use HTTP
headers to efficiently check to see if it needs to pull down the list
again or not.

Querying /nki/ alone would return a JSON (or HTML) list of all packages.
The original NKI list could be called, 'classic' (as opposed to the New
Coke) or 'original'.

> So to recap a nki would contain
> * the message
> * package (or packages?) it belongs to
> * a 'last modified' version number

How about a last modified time instead?

> * some unique id to identify it by
> * propably some other fields like author and so on

> Im glad youre liking the idea :) Having a centralized submission/repository
> system would really be a blast. I can help with coding when this thing gets
> rolling.

The hard part about that system, to me, is making sure the NKI items
stay at least somewhat true to the original flavour. As they're
essentially free-text, who's to say that any particular item is better
or worse than another? But if there were a bunch of NKI like, "A stapler",
it would become watered down. 

This is a subtle thing and needs to be handled accordingly. This is a
social thing and should be handled that way too.

-- 
Steve Pomeroy
http://staticfree.info/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://robotfindskitten.org/pipermail/rfk-dev/attachments/20090604/c22b9e97/attachment.pgp