On Tue, 2014-04-22 at 13:53 -0400, Tristan Van Berkom wrote:
> Sorry to interject, I don't have time to write such a lengthly email,
> but I would like to warn against exposing the database pointer in the
> EBookSqlite API to the world.
Hi,
no problem, I was waiting for your insight, to be
On Tue, 2014-04-22 at 14:13 +0200, Milan Crha wrote:
> On Tue, 2014-04-22 at 07:28 +, Potrola, MateuszX wrote:
> > I have one additional question about updating internal table by this
> > new module, should we add some new external API for EBookSqlite to
> > create/retrieve/modify backlog entr
> Is a great pleasure to announce that we will have 2 students, as GSoC
> interns, helping us (at least) for the next 3 months.
> We have announced a few ideas for GSoC and the selected students/ideas
> are:
> - William Yu: Add introspection support for the calendar backend
> - Watson Yuuma Sato:
On Tue, 2014-04-22 at 07:12 +0200, Milan Crha wrote:
> On Sat, 2014-04-19 at 01:06 +, Reid Thompson wrote:
> > Tried to build from git head and was getting build failures, so I
> > downloaded the latest stable .xz files -- getting the same failure. Can
> > someone point me to what I may have w
On Tue, 2014-04-22 at 07:28 +, Potrola, MateuszX wrote:
> I have one additional question about updating internal table by this
> new module, should we add some new external API for EBookSqlite to
> create/retrieve/modify backlog entries or the module can operate
> directly on the database usin
> The local address book uses EBookSqlite, thus what about making it an
> EExtensible? That way, with some EBookSqlite (internal and external) API
> changes, you would be able to create a new module, which will be loaded for
> each EBookSqlite instance and which will be able to step in during
> e_b
