iLiad The iLiad OS Project roadmap discussion

[Antartica]

I think that there is a need to state our personal preferences on what should be done first and the milestones to reach, so here is this thread.

Hope that we can get to some consensus .

[Antartica]

Before stating my personal preferences on the roadmap, one thing about the changes we introduce:

If we substitute programs, we should preserve protocols and file formats, even if they are far from optimal (but we can add another protocol in parallel if it's convenient). This is to try to not produce a maintenance nightmare (programs should stay compatible with new versions of the iliad os).

So, now my proposal:

milestone 1: preliminaries

• document the needed file formats and proocols prior to changing anything . The protols I would like to have are:
  • iliad_einkfb (dev/fb0) protocol
  • erdm protocol
  • eripc protocol (that includes matchbox-panel and busy led???)
  • scribbles file format
• have a way to create firmwares for the iliad and to flash them (and also to restore original 2.12 version)

milestone 2: minor usability improvements

• Substitute displaymgr wit xepdmgr, but having xepdmgr (a) understand erdm protocol in addition to his own protocol and (b) make sure that it can still be used as a wrapper for ported programs so they also work with 2.12.
• Enhance contentlister with the "low hanging fruit" tickets (number of elements displayed, ...).

milestone 3: boot time; goal: 10 seconds

• investigate the following possible paths (apply the ones that yield results):
  • scrap the systemV rc.d-style init and doing a more embedded approach: just a script launched from inittab that loads the modules we need and start the xserver and the shell (contentlister)
  • scrap even init (hence also inittab) and load a sh as process 0, that does the same as the previous entry
  • change the panel and contentlister so they use a smaller and faster loading toolkit (or none , and using prerendered font to avoid messing with freetype)

With that I would be happy enough for a 1.0 version (ups, 2.13, that is ).

Next in the list (for subsequent versions) would be start making a reality the UIs dicussed in the UI discussion thread

[Adam B.]

Here's what I think should be done in no particular order:

• Build a custom reflash image
  • Reflashes with latest updates (2.12.1)
  • Include FBReader (replace browser/minimo for html?)
  • Update registry with FBReader and SH file associations so requesting after reflash isn't necessary
  • Include Feedbooks application and connection scripts(?)
  • Include Automatic downloader framework and sample scripts
  • Include Dropbear, but do not start on boot
  • Include USB Keyboard support (*)?
  • Update Busybox
  • Include .lit converter
• Update contentlister to provide more than 6 files at a time
• Improve boot time and/or provide sleep or hibernate
• Multi button stylus support with eraser in scribble application

This is just off the top of my head. I can very easily build the latest reflash image.

[ericshliao]

I think that categorization of feature or suggestion is needed. We should classify all opinions (comments or requests) into four (or more) categories: kernel level, system util and lib level, general UI level, and application level.
For example, updating busybox should be in system util and lib level. All requests for contentlister should be in general UI level. Improving boot time should be in kernel level.
The above four level is rough, maybe someone could provide a more sophiscated and proper categorization.

An example table might be illustrative to what I am saying:

                       | high pri.        med       low      experiement
----------------------------------------------------------------------
kernel              |
sys util & lib     |
UI                   |
app                  |

[jharker]

Great thread! Sorry it took me a while to post.

Here are my thoughts. I've stolen liberally from Adam's and Antartica's previous posts in making this list. I have tried to put items in a practical order, so that prerequisites come before advanced steps. I figure things will be moved around if they happen faster or slower than anticipated. I have also tried to put widely-requested UI improvements early, and substantive under-the-hood improvements into later versions.

Versions 2.16-2.19 are sublabeled as "alpha" releases, as most of those changes will be under the hood and will require major testing before a "general public" release. They are also not really fixed in terms of order, I just tried to group related tasks together and keep each version down to a manageable size. We don't want any single version to be so big that it never gets done!

I have probably forgotten to include many major tasks.

What do you think?

First milestone: SVN server contents

• "Trunk" : all iRex-released source codes
• "Upstream" : all necessary upstream applications and libraries (i.e. busybox, gtk, kernel, etc.), with versions currently used on the iLiad.
• "Filesystem" : a perfect copy of the current iLiad filesystem, with all libraries, programs, etc. Suitable for distribution.
• SDK?

As new programs and libraries are updated and tested, the newest binaries will be copied into the "filesystem" directory, which will (ideally) always hold a working snapshot that could be installed on an iLiad. The snapshot will be tagged for each version release.

One question: how and where should we maintain the SDK? I do think we should provide a single, simple community SDK, along with clear directions on how to set it up to compile programs, libraries, and the kernel. But I don't know the best way to maintain something like that.

2.13 - Community software

• Based on latest iRex release (2.12.1?)
• Include established, proven community software that substantially increases functionality:
  • FBReader
  • Feedbooks
  • Dropbear/SSH
  • No iPDF changes yet
  • Others?
• Registry updates so all new programs are called to open "their" files types. Associate html files with FBReader. Include sh script support.
• Produce a reflash image of 2.13 suitable for flashing from a CF card.
• Produce a reflash version of iRex 2.12 for reference, and to make it easy for users to revert / uninstall the community OS.

At this point I think we will have established basic development capability.

2.14 - More programs, and community iDS

• Introduce Community iDS server
• Add "one-press" upgrade ability to iLiad.
• Add "Programs" folder to ContentLister for running programs not associated with a file type (Sudoku, etc.?). This avoids having to put them in "News".
• Second round of community software additions.
• Introduce automatic conversion/handling of file types (.lit, etc.)
• Simple boot speed improvements via streamlining (if possible).
• Other small, easy improvements not significantly affecting GUI.
• Bugfixes
• Dev Goals
  • API Documentation: toolbar, erdm, eripc, etc.
  • File formats documented: scribbles, folder manifests, etc.

After manually installing this version, users will be able to get new version updates from the community iDS server instead of the official iRex iDS server. New versions will not be released to the community iDS server until they are beta-tested. Of course, we will also provide new versions as reflash packages. I strongly suggest that we provide a "revert to 2.12" option in the Settings menu of this release.

Bear in mind that no one has worked on how to set up an iDS server as far as I know. If this proves to be difficult, we may have to push back the iDS item, and only release reflash packages for the time being.

2.15 - Major features / UI / GUI release

• UI/GUI revisions to toolbar, button functions and menus, according to goals determined in the UI discussion.
• iPDF: add community and new desired functionality (fullscreen, search, etc.).
• Modify other programs (FBReader?) to improve GUI consistency?
• Modify ContentLister to allow multiple documents/programs open at once.
• ContentLister GUI changes to add desired functionality:
  • More files visible (6,12,24?)
  • Read/unread checkbox, current page info
  • Scribble/note box
  • Rating in stars
  • Allow sorting, searching...
  • Etc., see this thread for ideas.
• Settings manager allowing full customization of UI preferences, along with easy "iLiad classic" and "community default" options.

This release is pretty major and will take some time to implement, I think. We will have to break it down into several parallel projects. Much of these are interdependent. For example, changing the toolbar and button UI should be done at the same time as adding iPDF features. The UI change also requires adding a menu to the ContentLister, in addition to new battery functionality.

All of these GUI changes will be planned by consensus. We won't introduce radical changes without vetting and feedback. These versions may go through several alpha/beta/RC steps to gain community approval, before it's released.

2.16 (3.0alpha1) - Infrastructure upgrade

• Upgrade all support programs (busybox, etc.) to latest versions.
• Upgrade all libraries (GTK etc.) to latest versions.
• Replace/supplement displaymgr with xepdmgr.
  • Update current applications to use the new library; OR
  • Include backwards compatibility in xepdmgr.
• Patch/modify major iLiad applications if necessary to handle these upgrades.
• Test, test, test.

2.17 (3.0alpha2) - Kernel upgrade

• Upgrade Kernel to 2.6 family.
• Trim unnecessary kernel options (if any) for speed improvements.
• Integrate all kernel modules directly into main kernel for faster boot (if reasonable).
• Obtain new versions of proprietary binary kernel modules for 2.6, or get/implement FOSS replacements.
• Maintain compatibility with applications/libraries.
• NO major changes in kernel functionality (i.e. sleep) in this release.
• Test, test, test.

2.18 (3.0alpha3) - Package-based update system

• Add ipkg frontend/GUI for easy selection/removal of community programs/packages.
• Restructure developer SVN server to allow separate maintenance/upgrade of individual packages.
• Revise community iDS to support package-by-package upgrading.
• Test, test, test.

2.19 (3.0alpha4) - Power management: fast boot / sleep / suspend

• Using 2.6 kernel, implement some variation of sleep/suspend if possible.
• Streamline boot process even further:
  • Revise startup scripts for fastest, most efficient normal boot.
  • Provide alternative "minimalist" boot for simple tasks.
  • New minimalist applications using smaller libraries for fast startup?
• Test, test, test.

3.0 beta, 3.0 release candidate - Public testing releases

• Minor feature additions
• Bugfixes
• Test, test, test.

3.0 - Major version release

This release should be the culmination of the last several milestones, resulting in a fully tested OS that includes most commonly-requested features as well as better libraries and infrastructure supporting future development. With this release iLiad OS can enter a phase similar to other Linux distributions, where individual software packages are maintained and updated independently, with periodic coordinated releases offering the latest feature changes and improvements.

Ongoing projects not specifically listed above:

• Add new community software. For inclusion, new software must:
  • be thoroughly tested and vetted, free of major bugs;
  • add significant useful features;
  • provide a smooth and efficient UI designed with e-ink refresh rates in mind.
• Software feature improvements:
  • Speed improvements (rendering, page turning, app startup time, etc.)
  • Efficient memory usage
  • Minor features and UI changes
• Under-the-hood improvements:
  • Code cleanup, add comments.
  • Write & improve API and general system documentation.
  • Split or combine programs for best efficiency and code clarity.

Questions, comments, additions, suggestions, criticism?

[Adam B.]

jharker, that seems like an excellent roadmap.

It wouldn't be too much trouble to build 2.13. I'll see if I can put together that firmware image (with instructions on how to build it) this week.

[Antartica]

Originally Posted by jharker

What do you think?
(...)
Questions, comments, additions, suggestions, criticism?

I think it's a very good roadmap .

For the comments part:

1. I'll definitely implement erdm protocol into xepdmgr, so it will accept commands both by UDP and by X atoms.

I think it has advantages to maintain it; using an UDP socket may be easier for some type of apps: i.e. SDL as they paint a frame and just "flip" it; also for scripts (tcl/tk, python...).

2. I would prefer to concentrate the efforts in the boot time/suspend issue solely in improving boot time, as with a very fast booting device suspend becomes a moot point.

To alleviate the time it takes to load a viewer (think ipdf with large documents) we could just save the last screen displayed for that document (and if it had some following pages prerendered, save some of them too).

Thats all

[Martijn]

I agree, a good roadmap.

I'd like to see a viewer framework in there somewhere so we can easily extend the number of formats, and so any optimizations (like Antartica's suggestion of saving the last displayed page) can be applied easily to all viewer plug-ins.
And if we could use the same API as the viewer framework for the DR1000, all the better

[jharker]

Thanks! I'm glad you like it!

Originally Posted by Antartica

2. I would prefer to concentrate the efforts in the boot time/suspend issue solely in improving boot time, as with a very fast booting device suspend becomes a moot point.

Good point, I agree. However, suspend-to-disk (hibernate) is essentially just booting with a custom boot image, right? So it might be that that's a way to easily get a fast boot time...? I guess we'll figure it out when we get there...

Originally Posted by Martijn

I'd like to see a viewer framework in there somewhere so we can easily extend the number of formats, and so any optimizations (like Antartica's suggestion of saving the last displayed page) can be applied easily to all viewer plug-ins.
And if we could use the same API as the viewer framework for the DR1000, all the better

I have mixed feelings about this... on the one hand, I agree that compatibility with the DR1000 is good, and I like the idea of having plug-ins that share a common UI and some common base code. On the other hand, iRex's base viewer code is proprietary (as far as I know) and I'm not sure we want to deal with that.

Also, I think part of the great thing about being Linux-based is that we can include existing FOSS viewers (i.e. FBReader, etc.) pretty much as-is, with only some relatively simple porting work. So I like the idea of having those as drop-ins without needing to revise/rewrite them to work with the viewer framework.

But anyway, I definitely think you're right, we need to make pushes for at least the following: a consistent GUI; adding common features to all viewers (search, bookmarks, scribbling, etc.); and adding support for more file types. If we can somehow be compatible with the DR1000 API, that would be even better! Maybe we can add a 3.1 milestone with some of these goals, including the goal of revising viewers to be compatible with the DR1000 API? At that point we could expand the iLiad OS to be a broader project, providing packages for the DR1000 as well?

I would love to see the iLiad OS become a useful standard e-reader OS that is portable to many e-ink based viewers, providing support for many, many file types... I think that milestone would be version 5.0 or something.

[Mr. Goodbar]

You guys are doing everything iRex should have. My development skills are non-existent, but I can certainly test and document as this progresses.

[thetechnobear]

any thoughts about upgrading the VMWare image to include the latest sources, perhaps setup to point to the shared svn repository etc.

my thought is simple, the easier it is for developers to get started , the more will be attracted to contribute....
(perhaps just me, but i like coding but hate the fiddling around to get the environment up and running ... and loved the way the vmware image has given us this.)

[thetechnobear]

oh one suggestion for an item
- safe boot

im sure we all have our own approach to this, but be nice for users to have in built-in...
seen so many threads saying, "i cant boot my iliad please help"
and im not sure how irex is going to respond to non-booting, community upgraded iLiads

oh, thought of another one
wireless networking - lots of people having issues with get connected to WPA networks,
... perhaps push some better network diagnostic software, and take a look at the existing scripts
(e.g. ive looked at, and they dont currently support static ip wireless networks)

[Adam B.]

Originally Posted by thetechnobear

oh one suggestion for an item
- safe boot

im sure we all have our own approach to this, but be nice for users to have in built-in...
seen so many threads saying, "i cant boot my iliad please help"
and im not sure how irex is going to respond to non-booting, community upgraded iLiads

Users will be able to download the factory reflash image. This should always work, and will be the same process as flashing the community image (at least until we can run our own IDS server). So if they can flash the community image, they should be able to reflash the original without a problem.

[Sonist]

Just wondering, what are the prognosis for implementing good power management, something akin to what the other 7000+ page-turns e-ink devices have?

[IanHelgesen]

Originally Posted by Sonist

Just wondering, what are the prognosis for implementing good power management, something akin to what the other 7000+ page-turns e-ink devices have?

Unlikely. Irex has stated that there is a hardware bug preventing this. It's possible that someone will come up with a clever work-around that the folks at Irex didn't think of, but...


As more my 2 cents on the roadmap (as a non-developer), this sounds great. The one other thing that might be worth adding is collaboration with the Open Inkpot project. Open Inkpot is also linux based (although I belive they use kernel 2.6), open-source, and aimed at e-ink readers, so there should be quite a bit of overlap. They have expressed an interest in creating an Iliad port, but I don't think anyone is currently working on it. Even if a full merger isn't feasible, we should at least be able to share improvements to FBReader. They also have their own content lister (Madshelf), which might be a suitable replacement for the current one (if the system functions are split into a seperate daemon).