View Single Post
Old 11-15-2008, 01:44 PM   #18
jharker
Developer
jharker could sell banana peel slippers to a Deveel.jharker could sell banana peel slippers to a Deveel.jharker could sell banana peel slippers to a Deveel.jharker could sell banana peel slippers to a Deveel.jharker could sell banana peel slippers to a Deveel.jharker could sell banana peel slippers to a Deveel.jharker could sell banana peel slippers to a Deveel.jharker could sell banana peel slippers to a Deveel.jharker could sell banana peel slippers to a Deveel.jharker could sell banana peel slippers to a Deveel.jharker could sell banana peel slippers to a Deveel.
 
Posts: 345
Karma: 3473
Join Date: Apr 2007
Location: Brooklyn, NY, USA
Device: iRex iLiad v1, Blackberry Tour, Kindle DX, iPad.
Here's a crazy question. Keep in mind this is very long term. Might it make sense to parallel and/or eventually merge this project with the OpenInkpot project?

The way I see it, each project has things the other project needs. OpenInkpot is working on various GUI programs that are specifically tailored to e-book readers. Meanwhile, iLiadOS has all of the hardware-specific drivers necessary to run programs on the iLiad. Rather than have OpenInkpot repeat a lot of work, it might make sense to have OpenInkpot focus on the GUI, while iLiadOS works to provide a standardized API and base filesystem for the iLiad. Then we could just drop the OpenInkpot GUI on top of the iLiadOS base!

Right now, I think a lot of the iLiad's hardware management is extremely non-standard. But it doesn't have to be this way. We can work to modify the drivers and eventually provide standard linux-style interfaces for the buttons, battery, touchscreen device, etc.

I only just learned about OpenInkpot recently, so I don't know anything about their development path. But it seems like the best way to make a widely-applicable reader software would be to make it modular, with a single high-level GUI (reader & library applications, config programs, etc.). Then you could have a set of interchangeable low-level filesystems for a variety of different reader hardwares. They would interface through a standard API for controls (keys, touchscreen, battery readings, etc.). The low-level stuff would take care of power management and hardware drivers. The high-level applications would just be changed slightly depending on the hardware UI configuration (buttons, touchscreen, etc.)

I know Adam is already thinking along these lines, because OpenIliad has loaned an iLiad to the OpenInkpot devs for testing. But we could actively lend out expertise to speed up the process.

Of course, in the near future we should continue working to improve the iLiad's existing applications, to provide improvements for current users of the device. But maybe we could aim to standardize the base drivers for use by OpenInkpot in the long run?

What do you think?

Last edited by jharker; 11-15-2008 at 01:46 PM.
jharker is offline   Reply With Quote