I think we run into a number of issues with MIDp today that we need to have a strategy for. Short-term, I see the JDBC-lite as the first step. Longer term, I don' think that the RMS is likely to be our only repository. It may be our only *shared* repository, so if we want to make use of records for contacts, etc. but in terms of application specific databases, I don't think we need to be limited here. Specifically, if we're doing a telematics application for a car company in J2ME for an on-board system, we may need to read from a database on a CD-ROM, or have a combination of RMS, CD-ROM, or remote datasources. Further, we might come to a conclusion that we want the database present in our code, and ignore the RMS entirely. Today, I unfortunately do *NOT* have a client driving the need for a SQL repository for the device [PALM, 9290, etc.], but I have no doubt all of us will. keith -----Original Message----- From: me-admin@enhydra.org [mailto:me-admin@enhydra.org]On Behalf Of Stefan Haustein Sent: Friday, September 14, 2001 1:39 PM To: me@enhydra.org Subject: ME: Re: RE: kDB >As I'm certain you know, you have access to the RMS, although the RMS is not >easily accessible by Java developers familiar with JDBC. Our thoughts >around kDB are two-fold, a superlight JDBC-like driver, and either a >replacement for RMS, or the ability to choose between either RMS or a new, >faster storage repository. I do not think it is possible to build anything independently of RMS that stores data in the device in Java. How could that be done? The only option is to build something on top of RMS because RMS is the only option to store data persistently on MIDP devices. That also means that it cannot be faster, except from using indices for lookup.... Best, Stefan _______________________________________________ ME mailing list ME@enhydra.org http://www.enhydra.org/mailman/listinfo.cgi/me |