db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Satheesh Bandaram <sathe...@Sourcery.Org>
Subject Re: default ij protocol (was Re: [WWD] review suspended)
Date Fri, 24 Feb 2006 20:31:08 GMT
Good discussion... Some comments, below..

Andrew McIntyre wrote:

>marsden	We were talking about your ij proposal.
>marsden	Will it confuse network server users who might
>marsden	1) Start network server
>marsden	2) ij> connect 'mydb;create=true';
>marsden	but will actually connect embedded.
>marsden	They won't figure it out until they see a dual boot message
>connecting from another jvm or find their database was created in the
>wrong place
>samcintyre	an excellent question. the answer is yes, maybe. definitely
>something to point out in the docs. I think one of Dan's goal for his
>holistic getting started approach was to get people executing SQL as
>quickly as possible. In this case it would mean not even starting
>Network Server.
IJ started using framework scripts today have default protocol set. So,
some users might already be familiar with connecting without protocol.

>marsden	ok
>samcintyre	I've always thought ij needed a way to default to
>connecting with the net client, but i've not thought it through much.
>samcintyre	perhaps a command line option? ij -client? something seems
>weird about that, but...
I thought we have two setup scripts, one for embedded use and another
for network server/client?

>marsden	Somthing. I don't know what. And a message "Starting ij in
>embedded mode. To connect to network server ..." or some suc
This sounds good... Though not sure if IJ would know at the startup
whether embedded or network mode is going to be used. Same IJ can be
used to connect to both local and remote connections. But if classpath
doesn't have derby.jar, may be it can assume client/server mode.

>samcintyre	(speaking of which, that's another thing ij needs, is a
>usage message a --help or -? option)
>marsden	I don't have any good ideas. I just found the default a little worrisome
>jta	--help would be great
>marsden	just more great stuff to do....
>samcintyre	actually, I think that's a great idea, Kathey. The ij
>embedded vs. ij client distinction has been a problem since network
>server arrived. A message stating which mode you're in, as well as
>instructions on how to switch modes seems to hit the mark.
>samcintyre	Yes, we always seem to be very good at coming up with
>things to do. :-)
>marsden	I remember when I first started with Cloudscape I had the
>hardest time getting my head around the idea of an embedded database.
>I cannot remember now why, but I know it happens to a lot of new
>marsden	Before you came, Deepa had made mention of DERBY-597 and J2ME.
>Whatever is done in terms of defaults, it would be good to consider
>J2ME and ij.dataSource as well.
>samcintyre	ok. haven't looked at 597 in a while. Seems like ij could
>detect a J2ME environment by checking JVMInfo and switch to a
>datasource, regardless of whether ij.protocol was set. That would
>require having a default for ij.datasource as well.
>samcintyre	yes, looks like 597 didn't set a default, just switches to
>use the datasource if no protocol is provided in the URL.
>Deepa[1]	checking JVMInfo sounds like a good idea. currently ij just
>checks for ij.datasource property and if found uses it to get the
>Deepa[1]	connect url should not have the protocol part in it.
>something like ij> connect 'mydb;create=true';
>samcintyre	yes. what if ij.protocol is set? I guess we could likewise
>detect a J2ME environment and not set a default protocol in that case.
>Deepa[1]	test harness sees if ij.dataSource is set and removes
>ij.database and ij.protocol from the system properties
>Deepa[1]	so we may need to do what you said "detect a J2ME environment
>and not set a default protocol"
>samcintyre	right, that would be happening in ij, not in the test harness.

View raw message