julienw_afk, ping

hey gsvelto

julienw, hey

julienw, so I was thinking, for the sake of this FxOS-lite project

julienw, why don't we have a look at migrating the SMS database do IDB in the next few weeks so we get rid of a nasty dependency?

I know this is not a priority but it's been on our list for so long

and now we don't really care if the work's not perfect (i.e. doesn't startup as fast, etc...)

we just want to not depend on the current in-gecko database

(nevermind the contacts, I'm not sure how we'll solve that one yet)

my main issue is that we need to improve the API to make sure the DB is consistent :/

we'll also need the API to be able to migrate BTW

julienw, yeah, my idea about that is to have a process that syncs the DB with the results from the API, with the DB acting as some sort of cache

so we read it first, then sync with the API

once the API is gone we'll just use the DB

but I wanted to know if you want to spend some time on it (reviewing, etc...) before writing any code

personally I'd be really happy if some of our core apps are kept alive in an almost web-compatible way

I'm all for that, but please think through all cases, especially look at some etherpads we created in the past. it's not _that_ easy...

think what happens when we receive a messgae for example

I know it's not easy and the biggest issue is synchronization

(and consider the app can be killed between receiving the system message and saving the new message to the db)

yep

we'll have to cut some corners IMHO

that's why we designed the APIv2

but if there's a chance we keep the app around and maybe even evolve the gecko API (though in a different context) that's it

in the past

<gsvelto> we'll have to cut some corners IMHO <= but resulting to data loss ?

we're facing data-loss anyway

IMHO the biggest issue would be with the following scenario

app is not launched

and it has not yet populated the database

a message arrives, the app is launched and starts populating the database

another message arrives while we're still iterating over existing data

-> we lose the incoming message / end up in an inconsistent state

not sure I get you here :)

I think that's the biggest issue

<gsvelto> but if there's a chance we keep the app around and maybe even evolve the gecko API (though in a different context) that's it

sorry, ctrl-V accidentally

an incoming message yields an event on mozMobileMessage

so...

we'd have it here

:)

see bugzilla.mozilla.org/898364

yeah but we have to make our read-from-the-API-and-write-to-the-database logic aware of that

there is especially some code from me in Gaia

(not ready at all)

starting point :)

I was experimenting around a nice API

but was not really satisfied yet

there is a dependency to the API change

understood

well, I'll see what can be done in the current scenario

and if it's feasible

all I'm saying is that it's not an easy task at all

and you'll need to consider whether it's worth it

that's my biggest concern ...

yeah

what we wanted is a transaction manager in the mozAPI

so that gaia can tell the API "ack, I wrote down this information"

otherwise the API would send it back the next time gaia asks

francisco, BTW, will we disable rich paste then ?

julienw: don't know, wish we could have disable it by app

I don't think we can

(and honestly I don't think 2.6 will ever ship so we can just disable it completely)

(yeah I'm depressed today :p)