This is an implementation detail that we can worry about later. Right now we need to figure out what kind of resources we have and come up with a basic architecture. I'll try to come up with some documentation tonight on how it should all work. Then we can start putting some code down.
Yea thats true..then in that case we can make this nav system independent. Each client takes average speed per segment, picks a random gps cordinate along the segment and then submits the two (without any copyright map info being transmitted). The server should reverse geocode the point into a street segment using osm (aka i-95 between exit 5 and 6) and then submit that to the storage database. I would say start by tracking 3 hour blocks per segment and as the project grows that can be shrunk.
Yea documentation sounds good...probably some easy xml coms? Only question I had was how should we handle user authentication? That should probably be part of the basic architecture.
oh and side note: we should have the openOBD project web interface online in a day or two so you can add vin and dtc lookup to the list of services :)
Okay, so I've worked a little bit on doing some high level architecture of the system. What's cool about this, and what should get every FE author excited and involved is this creates a unified plugin architecture for all frontends. That means plugins written to interface with the cloud on RR will work on nGhost etc.
The client will be a thin .NET assembly (in c#) that basically does plugin management and provides interfaces to the FE specific code that will use the assembly. The plugins interface with different servers. One plugin (ie. plugin "A") could goto the OpenIVI server for traffic. While another plugin could go directly to google for the traffic data. It's up to the user to select which plugin he prefers to use.
The FE specific integration would be something like a service daemon for LinuxICE that exports the interfaces over dbus for other apps to consume. Or it could be a RR plugin.
The server will be a collection of individual web services on the front, and database and user account interfacing on the back. For user account management, the simplest and most secure approach is to integrate with vbulletin (in the case of mp3car) or drupal/joomla/random CMS. That way the user, who already has an account, can use the existing account management and security features of the existing content management system. User account interfacing will be very site specific, but there is no reason why OpenIVI can't provide a plugin to interface with a few of the more common ones.
The server is going to take more thought on it's implementation, but this will suffice for now: It should provide an interface to multiple plugin-based-backends. That way site implementations can choose at will to swap out backends with other backends that better meet their requirements.
Excellent. The thought had crossed my mind but i neglected mentioning it.Quote:
oh and side note: we should have the openOBD project web interface online in a day or two so you can add vin and dtc lookup to the list of services
This may not be phrased the best way but a lot of the client side architecture is actually concepts built into openmobile. We already allow data provider plugin x,y or z to pump data into a standard interface and then data can be retrieved by other plugins using exactly the same standardized interface. I don't want to shoot anything down but it seems like it might be a tad bit more client-centric then I had envisioned. For my FE at least that would involve doing everything twice for little benefit, and for others that is still a pretty sizable implementation requirement.
What about the possibility of focusing more on the server side and using standardized coms? If you use xml (especially rss) for server responses it becomes trivial to implement. Otherwise you have a performance penalty for an abstraction layer that may not be necessary. I guess it comes down to scale, I saw this as something that could be up and running in a few days given hosting space and a database. For Example:
I was thinking of using WCF-style web services standardized on the SOAP protocol. These are trivial to implement in .NET and no xml/protocol needs to be known by the client or server. VS and even Mono can generate code from the web service's. It also supports SSL and other forms of security which is nice.
If you haven't looked into WCF, do so. It's pretty nice.
I've used soap before but was never happy with the amount of bloat it generated (not a big deal on high speed connections but over 3g it certainly could). One of the projects I worked on was a large movie database. After transitioning to SOAP web services transmitting meta data for 100+ movies took almost 1.5x as long. We could definitely go that road it just wouldn't make the rr guys very happy. It also would limit the services offered.
Any word from mp3car on what resources they're making available?
One thing that I would encourage is a standardized 'wrapper' for program communication and a 'payload' of the actual information.
The purpose of the wrapper is to permit standardized exchanges to take place regardless of whether the program understands the payload information or not. That allows users the flexibility to do what they want in their own FE's while still making it adhere to the standard.
Perhaps we could also see whether there can be agreement on some SIMPLE concept definitions like 'next track' or 'pause' or what constitutes a playlist or the definition of a gps point and add that to the standard
Even if we can't, providing a wrapper allows those who don't agree on the definition to send their own version of that data inside the standardized packet and allows it to be handled accordingly. And, using a wrapper allows the standard to be flexible and extendable.
I'm having a conversation with mp3car tomorrow about this project. I'm going to ask for server space and propose the idea that Kev has for the user ID and management to be associated with the current user I.D. I'll also ask for some help from their web guy to build a simple web interface for managing the configuration of the apps.
They already understand that this is not a proprietary system and want to contribute to a crowd sourced project. Is there anything else we want to ask for from them?