[Angstrom-devel] [Angstrom-distro-users] Angstrom Opie 1.2.3 testing

[Paul Sokolovsky]

Hello Paul,

Thursday, January 17, 2008, 9:34:12 PM, you wrote:

> Paul Sokolovsky wrote:
>>   opie-image-16mb was my initial work in that direction, with the aim
>> to produce OPIE image which still contains basic PIM tools and fits
>> within 16Mb jffs2 file. That was was just proof-of-concept, must be
>> continued, and apparently by people who have real need for such
>> image.

> Well, if someone else out there wants to step up and help out with this,
> great! But I suspect the intersection of the people with such devices and
> the people with the inclination to work on the problem is a small set
> indeed. Personally I don't have any devices with such limited storage
> space, but in the interests of helping out those who do, in the mean time
> I will try to look at the problem myself (time allowing).

  Sure, why not. But that could be not the most productive investment
of your precious time, as a both Opie upstream and OE maintainer ;-).

>>   But before that would give any sustainable result, IMHO, OPIE
>> upstream should define its role among embedded GUI environments.

> Presumably by this you mean we should endeavour to optimise the code for
> size and keep this in mind when making changes? I don't think this means
> we need to give up on any particular features, we would just need to be
> careful.

  Not quite. Before going to optimize something, we should think in
what direction to optimize. Besides always default for OpenSource
optimization for maintainership effort, there're some other choices to
follow. I'll probably share my dream about Opie to give example of it.
So, IMHO, if Opie optimized for:

1. Size. I hope we all would agree that it is important trait of the
Opie, but how much weight that has for the future, or is it
essentially a "legacy feature", with more exciting new bloat coming
its way? In my dream, I see Opie being conservative, valuing staying
as is over adding anything new without that new being carefully
optimized first.

2. Generic device support. This would be much harder to agree on,
especially that Opie is currently nothing like that. But deciding on
this matter would help to lay out both: 1) future for Opie - is it
another dying out UI framework, which is being maintained in patchy
manner while resources last, or is it framework which is going to stand
firmly in its niche position for much time more, serving yesterday's
well-thought, unbloated technology to bring good UI interaction for
more and more devices; 2) how to solve pain-of-the-day issues, like
for example is more per-device reports should be collected and
per-device fixes should be made to infamous cursor keys issues, or is
it enough evidence that current device handling in Opie is not
scalable.


  Second question mostly belongs to upstream, so I kindly ask you to
consider where you want to apply your effort. First one however
directly affects distro integration and must be decided on soon, to
solve serious deficiencies Opie in OE has now. One such deficiency is
non-working Bluetooth. I don't if you do some serious rework of that
Opie part, but in my list, it doesn't work, and not going to work
unless some noticeable changes to either Opie or OE are done. That's
because OE (and Angstrom) has Bluez 3, which uses DBus and only DBus
for any IPC it may need (like asking for pin), and doesn't have Bluez
2, on which old-good Unix-based IPC Opie depends. And how to solve
this directly depends on the decision for question 1: if we don't care
about size, we're not going to have long consultations with OE on how
to resurrect Bluez2, but just throw in DBus in Opie and "just" write
a Bluez3-DBus-Opie auth adapter. (Btw, effort associated with dilemma
#2 is of the same order - it may easily take more effort, diminished
by lower outcome, to patch existing machine support classes
repeatedly, than to throw them all now, and write new one, adequately
treating current generation of handhelds).

> Cheers,
> Paul



-- 
Best regards,
 Paul                            mailto:pmiscml at gmail.com