A Call for Kindle Touch Development Standardisation

[wolftail]

I have installed quite a few apps on my Kindle Touch and I feel that the filesystem has gotten a bit messy with all these apps storing their files in different places and with different naming conventions. Therefore I have written some guidelines that should help us standardize development, keep thing more tidy and make application management a lot easier.
I have included the guidelines in PDF for easy viewing and in docx for editing purposes. If the guidelines prove popular I will insert them in the wiki in order to be easily accessible and updatable as needed.

PS. I hope that other developers will find these guidelines helpful and will adopt them. I await your (hopefully constructive) criticism.

[geekmaster]

I like the idea, but just because the USB drive is a FAT filesystem is no reason to use Windows file and folder naming conventions. I like two-letter variable names, and SHORT 3-letter lowercase file names in the LONG tradition of linux filesystems. I and others like mirroring the root filesystem to the USB drive to some extent, but to prevent USB drive clutter some people have been putting their stuff in an /opt folder on the USB drive (/mnt/us/opt/bin, /mnt/us/opt/lib). I have been putting some of MY stuff in /mnt/us/system/bin (and other folders in /system on the USB drive), but that carries the risk of people forgetting to copy files hidden in /system before formatting the drive, AND "/opt is shorter than /system" -- and as you can see, I need SHORT names to pack maximum content on each line and on the screen without scrolling (called "above the fold" in newspapers, and in webpage design), or I just will not support or use it.

So although I and others have felt a need for organizing our USB drive filesystem, I think the "opt" folder method is much preferred to "HBapplications" and other long windows-ish folder names. At least I did not see embedded spaces in the filenames...

I am also of the opinion that XML is so "yesterday" -- I much prefer smaller data packets flowing in my client/server apps, although at least JSON (used in the kindle) is a step in the right direction AWAY from XML.

So... good idea, but the implementation needs a lot of work before I will use it, so you are creating "yet another standard" here.

'The nice thing about standards is that there are so many to choose from.' -- Andrew S. Tannenbaum (disputed)

'Standards are the beginning of doom' -- Friedrich Wilhelm Nietzsche

'Mediocrity finds safety in standardization.' -- Frederick Crane

'K: (n., adj.) a binary thousand, which isn't a decimal thousand or even really a binary thousand (which is eight), but is the binary number closest to a decimal thousand. This has proven so completely confusing that it has become a standard.' -- Tonkin's First Computer Dictionary

'Multilevel standards are like onions. They're smelly and make you cry a lot.' -- Ron Natalie

'Geez, you'd think standards were a continental disease or something.' -- Brian Reid

'If there was a single standard for the English language it would not be necessary to support redundant spellings.' -- OSF1 ls(1) [man page]

'Standards is an area that is constantly changing.' -- Carl Cargill (ed. ACM StandardView)

'Standards are always out of date. That's what makes them standards.' -- Alan Bennett

'How'd it go? "hundred madmen raping a girl for a week and conceiving a homicidal maniac - perfect allegory for ISO standard development process.' -- Al Viro on standard commitees.

'It indicates your bios authors can't read standards. Thats a quite normal state of affairs, so common that the kernel cleans up after them.' -- Alan Cox

'[the] W3C couldn't make bread without at least three different commitees and several hundred megabytes of XML involved' -- aiju

'standards are increasingly being viewed as competitive weapons rather than as technological stabilizers.' -- [James Gosling, Aug 1990]

... bad notations can stifle progress. Roman numerals hobbled mathematics for a millennium but were propagated by custom and by natural deference to authority. -- Doug (quoted in "the hideous name")

'It is not enough that X be standard, it should also be good.' -- Rob Pike (Window Systems Should Be Transparent)

EDIT: This is fine for a rough first draft, but the kindle is a linux device, so lets work on making this less "Windows-ish" and more "POSIX-ish" before we vote to ratify it as a new standard. I agree that we NEED a "standard" (just not this one), so I am giving your some karma points for your ongoing effort, but not the full 2600 (perhaps 500 is about right.) [The system will not let me add any karma to you until I "spread some around". ]

[wolftail]

I never meant for these to be final. Just a starting point. That's why I suggested the creation of a Wiki page, so that anyone may contribute and and reach a final standard that will please most developers. A wiki page would be perfect as well as it can have a discussion page where ideas can be debated. (I even included in the title of the document version 0.1 because I knew the guidelines were far from being finished or usable.)

As for the Windows-ish nature, you got me. That's what I am familiar with, so it influenced my design a lot. But there is no reason we should stick to my naming convention. (I have even written some alternative names for the HBApplications folder in the document). All ideas should be put on trial and open for debate.
Regarding XML files, again, I was more familiar with them so I used them instead of json in my first implementation of the guidelines.

To be honest I used the current implementation of the Launcher as a starting point and "borrowed" from it what I believed that would work best and make it easier for developers.

I am familiar with that comic strip from XKCD , and I am aware of the risk of creating just another standard that nobody will use. But I believe that if most of the more influential developers (and also those who create most of the homebrew content) get together and join forces, a solid standard will emerge that most people will adopt.

Originally Posted by geekmaster

... bad notations can stifle progress. Roman numerals hobbled mathematics for a millennium but were propagated by custom and by natural deference to authority. -- Doug (quoted in "the hideous name")

Another reason for proposing these guidelines is the fact that the platform is still young and most people use their own preferred conventions therefore it gets messy as I stated earlier and can be seen in your quote. Also, if a standard is created now (even one that evolves in time naturally from everybody's code without intention), it will be very hard in the future to change it as the platform matures. That's why I believe that we should act now and give development a custom controlled direction that will also be favorable in the future.

I wish I would have made it clearer from the beginning that my proposed guidelines were just a starting point for a common agreement and NOT just some standards that I and only I like and want to impose upon others.

[NiLuJe]

We've already had this kind of discussion once (will try to dig up the thread), and it didn't end in a very definitive way, AFAIR, but, hey, I'm all for it! Good luck .

EDIT: Found it. Starts in the middle of the K4 JB WIP thread.

[qlob]

This should also go for all e-ink kindle hacks not just K5(touch) as well. I have an extremly unorganized /mnt/us.......

[geekmaster]

Originally Posted by qlob

I have an extremly unorganized /mnt/us.......

I think you can fix that with a reformat, or a recursive delete from the root.

[aditya3098]

And that's extending https://www.mobileread.com/forums/sho....php?p=1985217

[geekmaster]

Actually, out of all the "standards" to choose from, there are two GOOD standards:

UTF-8: Not insane like all the alternatives.
JSON: Much less insane than XML.

ALL other standards are insane, confining what is "allowed" to only what is familiar and comfortable in a "designed by committee" "multi-cultural" mess, pretty much outlawing exploration of new frontiers for people like myself. Between standards, software patents, and "open source" code infected by the "GPL virus" making it useless for commercial programmers, software development can get somewhat difficult at times.

[ixtab]

Hmmm...

This may be getting philosophical, but I disagree on the JSON-vs-XML thing.

JSON is a format whose sole purpose is to represent data structures in a format that is both machine-readable and (somewhat) human-readable.

XML is a format that is meant to represent information in a machine-readable format, which is human-readable as well.

Everything that can be represented in JSON can be represented in XML as well. But the opposite is not true, simply because XML is much more expressive than JSON.

Before this gets out of hand: XML is indeed an extremely "noisy" way to represent things. The actual information tends to get buried inside the representation, simply because the metadata occupies much more space than the actual data. There have even been scientific papers showing that a very efficient compression algorithm for XML simply considers the differences between the instance and its schema definition.

I know about these, and I'm dealing with XML (SOAP, in particular), in everyday life. I have been cursing about SOAP and XML almost every day. But the point is: just like REST is not an alternative to SOAP, JSON is not an alternative to XML. Both lack the expressiveness that XML provides. In other words: they are not able to provide a concise description of their own data (format), which is essential for automated communication. And as much as XML drives me up the wall at times: A SOAP webservice can clearly describe itself, its interfaces, and its data structures, using WSDL. WSDL is based on XML Schema, which can actually "define itself", being based on XML.

There is nothing wrong with using JSON for simple tasks, if you know the data format beforehand. And of course, there have been atrocities like simple configuration files being "encoded" in XML. XML *can* describe pretty much everything (including itself), but that doesn't mean that XML should be used everywhere. Agreed. However, I disagree to condemn XML entirely. There are valid reasons to employ it, especially when things *do* get complex.

[geekmaster]

Originally Posted by ixtab

... However, I disagree to condemn XML entirely. There are valid reasons to employ it, especially when things *do* get complex.

Okay, I was employing a bit of levity (the opposite of gravitas) to the situation, but in reality I come from the opposite end of the programming spectrum, using things like application-specific languages and data-layout-aware custom compression (which by the way can compress FAR more than generic compression that does not know or care about data layout or data content regularities or restrictions, which can be taken advantage of in a HUGE way). And application-specific interpreted languages can vastly shrink and simplify otherwise huge and complex programs. Programming in a custom language that "knows" your data can really make things easy, simple and efficient. Graphics display lists are one simple example of this, and so is JVM bytecode, but you can extend those to include application-specific extensions where one instruction replaces hundreds of lines of complex code. You can do some of this with C++ operator overloading, but that can get so nasty, and representing your "subroutine call" as an "machine code instruction" is just so damn efficient.

It is not that I hate XML or other big nasty ways to deal with complex issues, but I prefer to change the rules so that I can define my data and my data management language into a cohesive and simple integrated solution.

We just have different ways of looking at the world of programming, and much to my luck, I have been able to navigate myself into a position in which I have the freedom to do so, unlike so many other unfortunate souls. Well... that and NIH, of course.

EDIT: And of course, I like streaming display lists across networks instead of JSON or XML, which is essentially what UltraVNC does when it sends windows graphics primitives across the link from its virtual video device driver intercepts, except I do this for all my client/server stuff. What can be more efficient than telling the device on the other side how to "do it yourself" instead of sending all the raw data. And where you cannot tell the other side how to regenerate the data, you use custom compression that knows about your data (perhaps using a pre-shared compression dictionary derived FROM your data).

EDIT 2: Of course, my methods restrict me to data that can be "pre-processed" allowing me to build a custom compression dictionary and/or minimal perfect hash function from my data. It helps that I choose problems that fit my tools, rather that being forced to use nasty XML stuff because there is no other reasonable solution. Like I said, we are coming at this from opposite directions, which define what tools we can use and what problems we can solve. The world needs both of us, or many problems will go unsolved. In my case, XML is not cluttering up my toolbox, and I intend to keep it that way.

P.S. I gave a hint about my perspective when I signed up here (Bare Metal Bit Basher). Here is one of my favorite web pages (which I STRONGLY recommend that you read): http://aggregate.org/MAGIC/