[rfk-dev] NKI filetype

[Steve Pomeroy]

On Thu, Aug 20, 2009 at 10:07:13AM -0400, Thomas Thurman wrote:
> There are now versions of robotfindskitten for various mobile devices
> (notably Android and Maemo).  I believe it would be a useful enhancement if
> these devices were capable of sharing lists of NKIs over Bluetooth.  There
> should be some amount of standardisation to allow sharing of NKIs between
> robotfindskitten implementations on differing platforms.
> 
> Therefore, I propose that:
> 
> 1) Any file received whose name ends in the four characters ".rfk" is
> presumed to be a NKI file.  The canonical name for NKI files is
> "non-kitten-items.rfk".
> 
> 2) NKI files consist of zero or more NKI descriptions, separated by carriage
> returns and/or linefeeds.  There is no header and no magic number.

In following with discussion back in June, I suggest that a very simple
header be added. This would just be in the form of:

--- cut ---
Key: value
Key2: value2

nki1
nki2
nki3
--- cut ---

This would let information, such as dates, categories, authors, favorite
soups, etc. to be added so that the NKI lists could be shown in the
GUIs.

As I suggested before:

A validating header regexp would be: ^[a-zA-Z][a-zA-Z0-9-]*: *(.*)$
And all keys would be case-insensitive, but would be suggested to be
transmitted in Title-Case.

Keys to start could be: Title, Author, Soup

> 3) NKI files are formatted in UTF-8.

I suspect this is already the case. If writing an RFC, I'd say this
should be a SHOULD and that encodings be properly labelled and
respected.

> 4) Should a MIME type be needed for NKI files, it should be
> "application/x-rfk-nki".

Shouldn't this be "text/x-rfk-nki" as a fallback to text/plain is
entirely reasonable? 

> 5) On receipt of an NKI file, the implementation should compare it with its
> own set of NKIs, add any which exist in the incoming NKI file but not in the
> current set of NKIs, and discard all duplicates.

I disagree with this. I think that the NKI resource objects mentioned
above should be treated as a "library" and be toggleable in the UI. So
if one were to receive a "kittens of the world" NKI set, one could then
disable it before handing it over to an already potentially confused
nephew.

The RFK implementation should of course follow what you outlined in 5)
given the set of enabled NKI.

Lastly, this should be left up to the implementation and should really
only be a recommendation.

> 6) The implementation may ask the user for confirmation before doing this.
> If the file was received over Bluetooth, and if the platform already asks
> the user for confirmation before receiving Bluetooth files, this step is
> unnecessary.
> 
> 7) If the NKI file was received over Bluetooth, it should then be deleted.
> Users should not have to deal directly with NKI files left lying around.
> 
> Does anyone have any suggestions or enhancements?

We should try and get this into the RFK RFC.

Android doesn't support file transfers yet, so there's plenty of time to
figure this out before we have P2P RFK NKI IRL.

-- 
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/20090820/8c6157ad/attachment.pgp