On Wed, 30 Nov 2011 17:09:03 +0200, mariuz <mariuz@...-dev.ro>
wrote:

>> It is more complex than that: Firebird internally uses an

implementation

>> of the JCA ManagedConnectionFactory which is defined in the JEE JCA
>> specification (one of the reasons Jaybird requires that
>> mini-j2ee.jar/jaybird-full.jar). These classes are definitely not part

of

>> Android and would therefor require a significant rewrite(*), and also I
>> am
>> not sure if the JSE and/or JEE licensing would allow recompiling the
>> required JCA, JTA and/or JDBC interfaces to Dalvik. That other drivers

do

>> this is - I think - not sufficient reason for us to do this (especially
>> considering the other work that needs to be done on Jaybird).

> I have seen some idea to make some of the methods stubs
> but again is still a lot of work
> http://download.oracle.com/berkeley-db/docs/je/3.3.62/HOWTO-Android.html

Those aren't method stubs, those are the XA transaction interfaces as
specified by the JTA specification, and which are implemented in the core
of Jaybird.

>>
>> But even more than that: in my opinion you really should not use JDBC

on

>> a
>> mobile phone to connect to a database (except for a *mobile-local* db
>> like
>> SQLLite). Database connection protocols, especially those of Firebird,
>> are
>> not really suitable for use over the relatively high-latency mobile

phone

>> connections. Secondly the chattiness of the protocol and processing
>> required might not be entirely battery friendly. As I said before, I
>> think
>> you are seriously better off (in terms of performance, security,
>> flexibility and scalability) to build a webservice that is accessed by
>> the
>> phone app. The added benefit is a simpler, leaner phone app, a clear
>> separation of concerns and a much simpler way to port the app to

multiple

>> phone platforms (you don't need to replicate the entire database
>> connection
>> part, just the UI, interfacing with the webservice and maybe some
>> additional local logic).

> you can use firebird protocol over ssh/ssl if you want
> but that is another discussion :)

That still doesn't remove the risk of having your database accessible over
the internet (granted SSH and SSL client side certificates could solve that
partly, but will mean deployment hassle)

> It would be nice if firebird could talk jsonp or some rest protocol
> directly
> Open http port , and then speak to the firebird directly
> something like
>

http://www.flamingspork.com/blog/2011/04/21/http-json-alsosql-interface-to-drizzle/

I happen to disagree. It leads to an extreme proliferation of various
(error-prone or unsafe) ways to talk to a database, instead of a single
well-tested interface. The solution already exists: build webservices
specific to your application, handle the exact communication to and from
the database in that webservice, you could replace the entire backend
structure from flatfile to Firebird to Hadoop and back without having to
change your client application.