OSDash Genesis Thread - Was: OpenVIS - The Open Vehicle Infotainment Service

[tripzero]

I edited the sf.net project description/name to openVIS. I can't change the unix name right now because sf.net's renaming service is down...

[Bugbyte]

Along the same lines, i think it'd be useful to keep statistics on what kind of trouble codes people get and associate that with a model/make/year. Users can then look at the data and identify future trends for their vehicle.

Like that idea quite a bit! If openVIS is successful, I'd expect a number of very interesting ideas about services that we haven't thought of right now (street sign ocr, anyone?)

[ioi8]

One idea for a webservice is usage tracking. It would actually be good to know what people are doing with their front-ends. Are the people using music playback or radio the most? Are they changing screens alot, or do they use one app for a long time?

Answers to these questions can really help FE designers optimize the most used applications and also put the most relavent info and effects with the least number of screen presses.

While some may say this is invasive, I am all for getting accurate data. At this point in time, can you honestly say how often people use a particular FE and for what purpose? Its just not possible without a webservice like this.

[justchat_1]

Speaking of if its successful...back on track... kev where are we on the architecture layout?

[tripzero]

Okay, I've got a little more details. This follows a similar pattern to what Matt and I have been already doing.

The following diagram shows the pattern (Also known as the "strategy pattern"):

Attachment 57382


For this pattern, I will describe an example for the Gps Tracking/Traffic service. The pattern should apply to many, if not all other web services on the system. First we have our web service methods. This is what WCF will expose over the internet. For our example, we will likely have 2 methods:

void Announce(string user, string passhash, double latitude, double longitude, double speed)
void Announce(double latitude, double longitude, double speed)

These methods will connect up to the backend via an interface. For our example we'll call this IGpsAnnounceBackend. We can hook this interface up with a concrete object using a "Factory". Factories will read the configuration and load the proper assembly at a site-specific level. For our example, we will likely only have one plugin as a backend, but because of the low cost to implement this pattern, even for services that we only contemplate having one backend.

void Announce(..)
{
   IGpsAnnounceBackend backend = Factory.GpsAnnounceBackend();

   backend.Announce(....);
}

For methods that require an account, a factory can be used to grab the account management backend:

void Announce(..)
{
   IUserAccountBackend account = AnotherFactory.GetAccountBackend();
   IUser user = account.GetUser(username, passhash);
   if(user == null)
   {
     ///fail
   }
   else
   {
      IGpsAnnounceBackend backend = Factory.GpsAnnounceBackend();
      backend.Announce(user, lat, long, speed);
   }
}

Most account managers track users by a UID of some sort. The backend should reference its data with this UID when applicable.

It'd be nice to use NHibernate or something similar as the database backend.

I'll see if I can get us some server space to start a wiki so we can get this all documented.

Okay, no it's time to plug the holes in my plan! From what I can tell, Matt is excellent at creating the web service and even creating the backend, hooking up with account management stuff etc. Justchat_t, from his experience in is really good at the middle stuff: the factory, the plugin loading, etc (although I'm sure he could do any of what I described above). I can help wherever needed as well. Hopefully we can get a web frontend guy or two as well.

[justchat_1]

For the most part it sounds pretty do-able:

Few things I would add:
1) To Allow for mirrors, load balancing and service changes first step should probably be to get the list of services (just a mirror list for each service) from the server. Maybe we could do that as part of the login step but that would require a login from every service
2) This example uses announce for the client->server, were you thinking of a seperate call for the server->client or should they both happen on announce and the client then retrieves the response from the factory.
3) Will this simple concept hold up to things like the music sync database? File streams are not something you want to pass around with function calls. I also was just thinking for the music sync service, having it use the local network first to grab data from the server and then fall back to the web service if not available could help with bandwidth issues.

[tripzero]

For the most part it sounds pretty do-able:

Few things I would add:
1) To Allow for mirrors, load balancing and service changes first step should probably be to get the list of services (just a mirror list for each service) from the server. Maybe we could do that as part of the login step but that would require a login from every service
2) This example uses announce for the client->server, were you thinking of a seperate call for the server->client or should they both happen on announce and the client then retrieves the response from the factory.
3) Will this simple concept hold up to things like the music sync database? File streams are not something you want to pass around with function calls. I also was just thinking for the music sync service, having it use the local network first to grab data from the server and then fall back to the web service if not available could help with bandwidth issues.

1) great thinking. The concept of mirrors had escaped my thinking, and without a thick client/assembly on the client machine, it really has to be done at the service level. We should also ask whether we want the service to provide mirroring at all. I know apache has built in stuff for load balancing across multiple mirrors. We have to do that for linuxice. I'm not sure if IIS has similar functions but I assume it would.

2) Right, I was thinking of a separate call the the client would make ie:

List<CoordinateSpeed> GetTraffic(double Lat, double long, double radius);

Where CoordinateSpeed is a struct of lat, long and speed (and possibly timestamp indicating when the record was created).

Something along those lines...

3) Media Syncing kinda breaks the pattern. It can very well be a hybrid approach where diffs are generated through webservice calls and some other method+protocol is used for the actual transfer between client and server. I've used SOAP calls to transfer files around which worked pretty well. I don't know how it'd perform over the internet with unstable connections. It could be that we just provide some services that making syncing with Amazon S3 or Ubuntu One easier.

[justchat_1]

1) great thinking. The concept of mirrors had escaped my thinking, and without a thick client/assembly on the client machine, it really has to be done at the service level. We should also ask whether we want the service to provide mirroring at all. I know apache has built in stuff for load balancing across multiple mirrors. We have to do that for linuxice. I'm not sure if IIS has similar functions but I assume it would.

Yea i'm pretty sure IIS has similar functions but I was even thinking of load balancing and redundancy across domains. That way if theres ever an ISP issue theres an alternate way to get info. You could even round-robin the response list so the balancing is automatic.

2) Right, I was thinking of a separate call the the client would make ie:

List<CoordinateSpeed> GetTraffic(double Lat, double long, double radius);

Where CoordinateSpeed is a struct of lat, long and speed (and possibly timestamp indicating when the record was created).

Something along those lines...

Gotcha...sounds good

3) Media Syncing kinda breaks the pattern. It can very well be a hybrid approach where diffs are generated through webservice calls and some other method+protocol is used for the actual transfer between client and server. I've used SOAP calls to transfer files around which worked pretty well. I don't know how it'd perform over the internet with unstable connections. It could be that we just provide some services that making syncing with Amazon S3 or Ubuntu One easier.

Im not even sure diffs would be that effective, most likely someone will either have an entire song file or no song file. We could do a basic sync service where we just call void Sync(string folderPath) and the factory would just grab new files since the last sync. Then the real work would be done by some client app that sits on your media server and figures out what music is new and transfers it to the web server. The only tough part is the first sync.

That could also tie in with my other idea of the default being a transfer over the local wireless network with the factory falling back to a web service transfer if thats not available.

[justchat_1]

*BUMP*

Ok to try to keep this moving lets get service definitions set. The first 4 that I had were:
> Online Playlist management
> Music Sync Services
> Vin and DTC lookup
> Online FE configuration (settings management)
but if we want to bump from or add to that initial list just let me know.

Definitions:
* Online Playlist management

• sendPlaylist(string name, string playlist) or (string name, string[] url)
• string getPlaylist(name) or string[] getPlaylist(name)
• string[] getNewPlaylists(DateTime start)

* Music Sync Services

• string[] getNewSongs(DateTime start)
• void getSong(string name,string dest)
• void sendSong(string url)

* Vin and DTC lookup

• struct vehicleInfo getVehicle(string vin)
• struct dtcInfo getDTC(int manufacturer,string DTC)

* Online FE configuration (settings management)

• string[] getNewSettings(DateTime start)
• string getSetting(string name)
• void sendSetting(string name, string value)

[n2k]

After skiming trou this thread my first question is why go with asp.net ? if it's going to be open why not go with something like python or php ?