<br><br><div class="gmail_quote">On Thu, Jun 4, 2009 at 3:02 PM, Harry J Mason <span dir="ltr"><<a href="mailto:hjm03r@ecs.soton.ac.uk">hjm03r@ecs.soton.ac.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">On Thu, 4 Jun 2009, Steve Pomeroy wrote:<br>
<br>
> On Thu, Jun 04, 2009 at 02:02:54PM +0200, Lajcik wrote:<br>
>> An update mechanism is definitely better than fetching a whole blob each<br>
>> time there's an update.<br>
><br>
> Why? This isn't a lot of data. Sure it could be more efficient, but<br>
> there are benefits to simplicity when it comes to implementing a<br>
> consumer.<br>
><br>
</div><div class="im">> My solution:<br>
> Just serve a JSON file which contains all the NKI. It should be as<br>
> simple as:<br>
><br>
> [ 'nki1', 'nki2']<br>
<br>
</div>I'd argue that plain text would be even better. One NKI per line, standard<br>
UTF-8 encoding; this would be trivial to parse in any language, requires no<br>
complex escaping rules, and is as small as possible.<br>
</blockquote><div><br>The only problem with this approach is that it leaves absolutely no room for future expansion, while few more characters that make up a well defined json object would allow adding stuff in the future without breaking any existing clients. example<br>
<br>{list: [{nki: 'nki1'}, {nki:'nki2'}]}<br></div></div><br>Gzipped (or even not) size wouldnt be significantly bigger but adding new attributes (if needed) would be a snap. <br><br><div class="gmail_quote">
On Thu, Jun 4, 2009 at 2:43 PM, Steve Pomeroy <span dir="ltr"><<a href="mailto:steve@staticfree.info">steve@staticfree.info</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">On Thu, Jun 04, 2009 at 02:02:54PM +0200, Lajcik wrote:<br>
> An update mechanism is definitely better than fetching a whole blob each<br>
> time there's an update.<br>
<br>
</div>Why? This isn't a lot of data. Sure it could be more efficient, but<br>
there are benefits to simplicity when it comes to implementing a<br>
consumer.</blockquote><div><br>You're right, i got carried away, even considering thousands of nkis in a package that would still be a relatively small file :) When i think about it what you proposed is both easy to implement and simple to use and suits the purpose perfectly.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">The hard part about that system, to me, is making sure the NKI items<br>
stay at least somewhat true to the original flavour. As they're<br>
essentially free-text, who's to say that any particular item is better<br>
or worse than another? But if there were a bunch of NKI like, "A stapler",<br>
it would become watered down.<br>
<br>
This is a subtle thing and needs to be handled accordingly. This is a<br>
social thing and should be handled that way too.<br></blockquote><div><br>Someone (or a small group of someones) should be able to say that 'a stapler' is not really in the spirit of things and dump it, otherwise the quality is at risk. Or choose not to include it in the official 'approved' package.<br>
</div></div><br>-- <br>My digital home - <a href="http://lajcik.org/">http://lajcik.org/</a><br>