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

Toby

Is what you've done publicly available?

Regards

Pete

--

Peter Hearty                         peter.hearty@lutris.com
Lutris Technologies (UK)        http://www.lutris.com
----- Original Message -----
From: "Tobias Downer" <toby@iglou.com>
To: <instantDB@enhydra.org>
Sent: Tuesday, October 31, 2000 9:17 PM
Subject: Re: InstantDB: Re: instantdb evaluation


>
> 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.
>

-----------------------------------------------------------------------------
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.