Aurora

[Simon Busch]

On 16.05.2011 23:22, Neil Jerram wrote:
> I'm afraid I don't understand.  Why not just have SHR as your
> reference set of applications?  If you don't think they are using the
> FSO APIs in the pattern that you would recommend, presumably you could
> work with them to correct that?  Or, if they are missing applications
> or features to showcase some of the latest FSO API features,
> presumably you could help them to add those?

SHR is a great thing, but it's too complex to be the first showcase for
new features. The main problem we have is time and man-power. We are
currentl two people doing most of the FSO work. With two people it's
even hard to get only the basics done.
SHR is based on the traditional design pattern of a window mananger
which runs some application you can work with. The work to integrate new
features like network (wireless, gprs, bluetooth pan) in a usable we
needs a lot of work (you need a new E Gadget, you need a application to
choose the network, you to adjust shr-settings, ...) to do.

I worked for now 2 two to get SHR running on the Palm Pre and it's so
much work that I will never finish it on my own. You invest a lot of
time to debug things, see how things work and never get your work
finished in a reasonable time frame.

>> At the top of every application stack is the user. Pleasing him or her
>> is the topmost priority.
> 
> Speaking as a user, I would be pleased not to see more unnecessary
> fragmentation of front-end efforts; also for the FSO2 middleware to be
> rock-solid, with things fixed like RequestResource('bluetooth')
> starting bluetoothd.

Aurora is not about fragmentation. Zhone was already there before SHR
and Aurora will continue Zhone. We will take aurora as our new reference
application as it is quite simple and let us integrate new features very
fast.

> To be fair, it may be that FSO2 already is rock-solid now.  I haven't
> reviewed the situation recently, but I can't immediately think of any
> known and clear issues, about from the bluetoothd one.  But in that
> case I'd still prefer focus on the SHR front end, over some new UI.

As you may know we are working hand-in-hand with all the SHR developers
and we are loving SHR too. But at some point we need to concentrate us
on FSO and FSO as framework only to be successfull in the future and not
only on the Openmoko devices. There are a lot of devices out which are
suitable to be driven by FSO but needs time to be integrated into the
framework. If we do everytime to full work for SHR and FSO we will never
do anything else with this phones in their lifetime. If you work for a
long time very hard on such a project you want to see something working
and usable to have. But currently with doing the doubled work for SHR
and FSO does not let us come the this point.

> If you strongly favour Qt, you could take QtMoko as your reference set
> of applications.  That would be especially helpful right now, as Radek
> is just looking at converting QtMoko to use FSO.

With QtMoko it's the same as I said above. We need some simple stupid
thing we can change within an hour to support a new feature like network
management. We cannot archive this with QtMoko or SHR.

> I'm almost lost for words here.  Starting from scratch seems so
> obviously the wrong thing to do, when there are mature projects that
> you could contribute to...

We are not starting from scratch with a completely new platform. We are
just reordering the reponsibility of the FreeSmartphone team which is to
develop the middleware and concentrate of integrating new devices and
get new features like network management in.

> I must be misunderstanding what you mean - please do explain more!

Don't thing about aurora as something big, it's a very simple thing for
simple needs. You will see all new features even in SHR, but not done by
the core FSO team.

regards,
morphis