[rfk-dev] androidfindskitten

[Peter A. H. Peterson]

Quoting 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.

Well, I guess the question is, at this point, will synchronization
cost more than a single gzipped transaction? For a few hundred NKI,
probably. On the other hand, doing what Lajcik suggests is more apt to
create a nice system which tracks changes to individual NKI, versions,
etc. I kind of like the ability to see the evolution of the NKI set.
Back on the first hand, though, a one-tarball approach is
approximately 73.4 times easier than the more complicated solution.
(And the versioning, etc., could still be kept in the backend to the
system.)

> 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.

Yeah, very straightforward. And it also seems reasonable to have the
client check only once every 24 hours or something like that. Not
we're going to get crushed by the hits... rfk will probably never be
the next gta. Thank gord.

> 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'.

Sure.

> > 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?

The way I'm envisioning it, there's a Django-driven website that
manages the NKI on the backend; I kind of prefer integral change ids
per NKI, but how that is presented to the user doesn't matter. If
we're doing the one-file thing, I'd just as soon have the user file be
the NKIs alone with no metadata (most users won't care about
metadata so it's a waste). As Steve said, you just mark the timestamp
on the file and do an If-Modified-Since query when you check for
updates. If users want to see the changelog history they could explore
the NKIs on the site.

> > 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.

I absolutely agree. For the record, I've always liked the idea of
having a central repository for submissions, etc., and of streamlining
the NKI submission process. It's just that if you completely remove
editorial control from the NKIs, it starts to reduce the fidelity of
the zen simulation. NKIs need to be unpredictable. While they can be
clever, if they're all clever, in the same way, then that's
predictable and paradoxically, no longer clever. Some will be mundane,
like "It's a stapler." But if they are all mundane, then it's boring.
NKI also need to have a somewhat consistent literary voice, so it's
conceivable that we might get a submission which is conceptually good
but needs to be reworded, etc.

In the past, the "editorial control" has basically been handled
through this group. I love democracy, but I'm not sure that a simple
"everyone on the mailing list votes" approach is best in the long run
thanks to the Internet effect. We need to make sure that whoever is
doing the editing really understands the spirit of rfk. I'm open to
any suggestions about how that should be done. As Steve said, it's a
social thing -- but it's also an artistic thing.

Anyone else, thoughts?

Peter



-- 
Peter A. H. Peterson, technician and musician.
 ---=[ http://tastytronic.net/~pedro/ ]=---