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

yup it's easy.

the java.io package has a class Serializable.

so all you do for example is have your server take a sql string and return
a ResultSet object through an OBJECT stream and NOT A DATA stream.
i.e. use ObjectInputStream and not DataInputStream for example.

so - when i said easy -> i meant it's easy to code not just conceptually.

I actually designed the frontend in 2 hours yesterday.

Remember, I cannot use the InstantDB system in unix unless i change my
umask which I cannot do for security reasons. So, this method is very
necessary.

any questions ?

Robert Milewski  (716) 645-6164 x538
Research Engineer
Center of Excellence for Document Analysis and Recognition
SUNY Buffalo

http://www.cse.buffalo.edu/~milewski


On Tue, 31 Oct 2000, 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
> 
> --
> 
> Peter Hearty                         peter.hearty@lutris.com
> Lutris Technologies (UK)        http://www.lutris.com
> ----- Original Message -----
> From: "Robert J Milewski" <milewski@cedar.buffalo.edu>
> To: "Peter Hearty" <peter.hearty@lutris.com>
> Cc: "Mark Diekhans" <mark.diekhans@lutris.com>; "instantDB"
> <instantDB@enhydra.org>
> Sent: Monday, October 30, 2000 5:37 PM
> Subject: Re: instantdb evaluation
> 
> 
> >
> >
> > There is a solution which you guys could design and it would be quick.
> > You design a quick server - all it does is pass SQL and Resultsets (for
> > example) through a socket - 1 socket per client connection. Then, on Unix,
> > whichever user the server is executed on will handle the permissions
> > automatically. So the server uses the driver and the .prp file to make the
> > jdbc connection and it waits on a port for a socket connection. So this
> > "server" which is less than 200 lines of code creates a 3-tier(
> > architecture?) making any operating system blackbox. You would not have
> > change any of the other database code you have, it would be independant.
> > An addon I suppose to your existing software.
> > Wadda ya think ? Would you guys be willing to design something like this ?
> > It should take less than a week.
> >
> > Please send comments - thanx =)
> >
> > Robert Milewski  (716) 645-6164 x538
> > Research Engineer
> > Center of Excellence for Document Analysis and Recognition
> > SUNY Buffalo
> >
> > http://www.cse.buffalo.edu/~milewski
> >
> >
> > On Mon, 30 Oct 2000, Peter Hearty wrote:
> >
> > > Robert
> > >
> > > AFAIK (and if I'm wrong - would someone out there please chip in and
> > > correct), there's no way to explicitly set UNIX style file permissions
> in
> > > Java. There are limited capabilities in the java.io.File class, but
> these
> > > are mostly interrogative.
> > >
> > > I think that means that, if you intend to access a database from
> multiple
> > > accounts, it's either a matter of setting up a group with appropriate
> > > permissions or manually setting file permissions once the database has
> been
> > > created.
> > >
> > > Any UNIX Guru's care to comment?
> > >
> > > Regards
> > >
> > > Pete
> > >
> > > --
> > >
> > > Peter Hearty                         peter.hearty@lutris.com
> > > Lutris Technologies (UK)        http://www.lutris.com
> > > ----- Original Message -----
> > > From: "Robert J Milewski" <milewski@cedar.buffalo.edu>
> > > To: <bugs@enhydra.org>
> > > Sent: Thursday, October 26, 2000 7:11 PM
> > > Subject: instantdb evaluation
> > >
> > >
> > > >
> > > > To whom this may concern,
> > > >    I am a lead design engineer evaluating java database engines for
> > > > one of our projects. While evaluating the latest release of your
> InstantDB
> > > > system in Solaris, I noticed that when I create or modify a table, the
> > > > permissions, user and group information from my umask is used on the
> file
> > > > for that table. This prevents other users from having read/write
> access to
> > > > that table. If there is something I have missed, please notify me
> ASAP. I
> > > > found your system easy to use, but I would not want to scrap it b/c of
> > > > improper handling of Unix permissions. Hopefully I missed something.
> > > > Thank you for your time. =)
> > > >
> > > >
> > > > Robert Milewski  (716) 645-6164 x538
> > > > Research Engineer
> > > > Center of Excellence for Document Analysis and Recognition
> > > > SUNY Buffalo
> > > >
> > > > http://www.cse.buffalo.edu/~milewski
> > > >
> > > >
> > > >
> > >
> >
> >
> 

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