Reply
Thread Tools
code177
2009-09-28 , 19:15
Guest | Posts: n/a | Thanked: 0 times | Joined on
#1
Okay. It's true - I had fun writing the thread title. But I also think it expresses what this thread is about, which is:

If you write an app that needs to talk to a database, hosted on a webserver, but you also want to release the code as open source.. what do you do?

I can think of a couple options:

- Somehow binaryize the connection information
- Write an HTTP based API (which would be slower and use more bandwidth )

It crossed my mind that you could leave the connection info in there, but then I realised anyone with the code could just go postal on the database, so that's obviously out.

So what's the convention here? I don't want to have to close-source my app when it's done...
Last edited by code177; 2009-09-28 at 19:16. Reason: edited for grammar
 
zerojay's Avatar
zerojay is offline zerojay
2009-09-28 , 19:17
Posts: 2,669 | Thanked: 2,555 times | Joined on Apr 2007
#2
Originally Posted by code177 View Post
Okay. It's true - I had fun writing the thread title. But I also think it expresses what this thread is about, which is:

If you write an app that needs to talk to a database, hosted on a webserver, but you also want to release the code as open source.. what do you do?

I can think of a couple options:

- Somehow binaryize the connection information
- Write an HTTP based API

It crossed my mind that you could leave the connection info in there, but then I realised anyone with the code could just go postal on the database, so that's obviously out.

So what's the convention here? I don't want to have to close-source my app when it's done...
What exactly are you working on here? It's hard to give you advice without more context.

You could always just create a new user/table per app user, I suppose and restrict access so that only the user can affect data in his table.
 

The Following User Says Thank You to zerojay For This Useful Post:
code177
2009-09-28 , 19:45
Guest | Posts: n/a | Thanked: 0 times | Joined on
#3
Originally Posted by zerojay View Post
What exactly are you working on here? It's hard to give you advice without more context.

You could always just create a new user/table per app user, I suppose and restrict access so that only the user can affect data in his table.
Let's say profile information as an example. Say you have a table with id, username, email, status, message, etc. You need to be able to insert and update, rows to this.

If it were just required to read information this would be easy, as you could just set the db permissions to read only. This falls apart when you need to insert and update though.

Perhaps a binary API? Does that break the "philosophy" of open source though? I guess if you released the binary's src files, but without any of the sensitive information it would be ok..
 
code177
2009-09-28 , 19:51
Guest | Posts: n/a | Thanked: 0 times | Joined on
#4
I guess you could go crazy and use SQLite locally (on the device) and somehow make the units connect peer-to-peer but I have no idea how you'd even start setting up a peer to peer system.
 
timsamoff's Avatar
timsamoff is offline timsamoff
2009-09-28 , 20:26
Posts: 1,605 | Thanked: 1,601 times | Joined on Mar 2007 @ Southern California
#5
Afaik, doing it via an API is the only way to accomplish this (a al Facebook, Twitter, Last.fm, you name it). Dealing with databases (other than local) is tricky and allowing others to view the source of how the DB is accessed opens up a huge can of worms. In this particular case, only allowing others to access and alter specific tables is key.

Tim
__________________
http://samoff.com
 

The Following User Says Thank You to timsamoff For This Useful Post:
Hogwash is offline Hogwash
2009-09-28 , 20:30
Posts: 369 | Thanked: 191 times | Joined on Sep 2009 @ Virginia
#6
If you're looking to provide some service that needs to store information, it would be insanity to open up raw access to the database to every client.

Why not provide a web service interface and have your client app throw xml at it?
 

The Following User Says Thank You to Hogwash For This Useful Post:
code177
2009-09-28 , 20:44
Guest | Posts: n/a | Thanked: 0 times | Joined on
#7
I guess making a web based API is the way to go though. I suppose I'll have to suck up the performance loss of direct-db access vs http call... but I suppose on the plus side I can do some server-side processing now, which is a whole other kettle of fish.

Thanks guys!
 

The Following User Says Thank You to For This Useful Post:
jsuggs's Avatar
jsuggs is offline jsuggs
2009-09-29 , 14:22
Posts: 103 | Thanked: 44 times | Joined on Sep 2009 @ Nashville, TN
#8
If all you are doing is basic insert update delete of things like users and basic objects, then your performance hit will be marginal with a web API.

The more interesting question/application would be if you were manipulating LOTS of data (1000s - 100000s) of rows per transaction. Then you would have a use case that was more suited to defining a lower level communications layer...but what would that application be that was running on a phone?

General rule of thumb is to not over engineer your application.
 

The Following User Says Thank You to jsuggs For This Useful Post:
Reply

« Previous Thread | Next Thread »

 
Forum Jump


All times are GMT. The time now is 07:29.

Contact Us - Home - Archive - Top