The Gears database API explicitly disallows the sqlite attach / detach commands. This design decision makes good sense to me, for the reasons given. Nevertheless the statement below indicates the possibility of flexibility. "In the future this functionality may be exposed in a way which respects the same-origin security policy."
I would like to use this post to make the case for limited support of attach / detach. My proposal is to allow multiple attached database files, with the caveat that they must be in the same folder as the main database file. This would ensure that same-origin policy is not violated, yet would enable a useful feature of sqlite. My objective is to facilitate a secondary vector for distributing data between users of my Gears app. The distribution mechanisms need not be fully specified at the outset. For example a client-side script, a P2P app or just plain old copy/paste/email would all be feasible, if the token of transfer were a single database file. Using the Gears app to create a separate database file would give the originating user control over what data gets transmitted this way (and what should remain private). I feel my proposed design would be more convenient and flexible for my users than, say, an export / transfer / import routine. It seems to me that Gears and sqlite database files have good synergy for Gears developers. Both Gears and sqlite databases are platform agnostic. http://sqlite.org/different.html (Stable Cross-Platform Database File). The sqlite developers have also committed to maintain backwards compatibility for their database file format. I suggest that other developers who feel that attach / detach functionality in Gears would add value to their own apps should voice their support to this post.
