InstantDB Project
About InstantDB
Project Mail Lists
Short History
Reporting Bugs
Screen Shots
3rd Party Examples
FAQs

Software
Downloads
Documentation
CVS Repositories
Roadmap
License

About Enhydra.org
Who We Are
News, Articles & Events
Getting Involved
Contact Us

Community
Demos
Contributions
Resources
Case Studies
On The Edge! -NEW-
Commercial Vendors

I take it this is what RmiJdbc essentially does?  It forwards each call
from the JDBC RMI client to the JDBC driver running on the server.

Peter, have you considered extending the IDB JDBC driver so it natively
works over TCP/IP?  Supporting scrollable result sets remotely is a very
cool feature.  If you were to look into natively supporting
client/server, you would benefit greatly if the communication protocol
worked at a lower level than the JDBC method calls.  You would lower the
amount of network traffic.  Only the 'execute' methods in Statement and
some of the metadata query methods would cause traffic.  ResultSet data
could be cached on the client.  And valuable resources would be freed on
the server.

You'd be surprised at how simple a low level JDBC communication protocol
can be.  We got it down to just four commands from client to server
(EXECUTE QUERY, GET PART OF A RESULT, DISPOSE RESULT, CLOSE) from client
to server.  The metadata queries could also be performed with EXECUTE
QUERY commands, and the updateable result set functionality can be
achieved by translating them into 'INSERT' and 'UPDATE' SQL statements.

Toby.

Peter Hearty wrote:
> 
> Robert
> 
> That's an interesting idea. I've often wanted to have a go at a lightweight
> server for IDB. Before discussing that further though, I'd just like to
> point out that there's the RmiJdbc driver available that already lets you
> use IDB in client-server mode. See
> 
> http://instantdb.enhydra.org/software/documentation/network.html
> 
> for details.
> 
> The problem I've always had with writing a dedicated server for IDB was it's
> sheer size. You're quite right - it's a very *easy* thing to do (very little
> actual thinking involved), but wouldn't it take a lot of time and effort? If
> all you wanted to do was send SQL up to be executed then the server would
> indeed be very small. Granted, that 90% of the time that's probably all you
> do want to do, but java.sql has hundreds, if not thousands, of methods that
> would have to be implemented. Wouldn't that involve inventing a line
> protocol to cope with all of these methods?
> 
> If you've got a really easy way to avoid all that work I'd be *really* keen
> to hear more about it.
> 
> Regards
> 
> Pete

-----------------------------------------------------------------------------
To unsubscribe from this mailing list, send email to majordomo@enhydra.org
with the text "unsubscribe instantdb" in the body of the email.
If you have other questions regarding this mailing list, send email to
the list admin at owner-instantdb@enhydra.org.