= Google Summer of Code (GSoC) Ideas Page =

The GSOC schedule is at [http://www.google-melange.com/gsoc/events/google/gsoc2012].

== Short Message Queue 2 Implementation(SMQ2) ==
OpenBTS messaging is currently served by smqueue, our SMSC (Short Message Service Center) replacement. This routes SMS messages between phones (and potentially outside networks). Smqueue has served us well, but it was started on a weekend with little thought to later use. We have to replace it. 

Goal: Begin the implementation of an Smqueue replacement. Details are [wiki:SMQ2 here]. There are a number of core properties derived from that page:
 * Dumb: SMQ2 should focus primarily on storage and forwarding of messages; short-codes are offloaded to an external service (FreeSWITCH or HTTP).
 * Database-driven: All messages should be stored in a generic SQL database.
 * Protocols: There are many ways to potentially insert a message into our network. We expect SMQ2 to support RFC-2438 SIP (IMS and plain text), XMPP, SMPP. This would (in the best case) be supported by a plugin interface.
 * Event-driven: As this engine does not do a lot of heavy protocol work, an event-based engine seems like the best fit. 

Languages: We would prefer the implementation to be in C++, as that is the most commonly used language in the OpenBTS community. We're also open to other languages that may be a better fit for some reason (i.e., python for a twisted implementation). 

!Mentor/Contact: Kurtis Heimerl <kurtis.heimerl@rangenetworks.com> and/or David Burgess <david@rangenetworks.com>

== WebUI ==
OpenBTS relies upon the subscriber registry to manage users. This is a database where all of the information about OpenBTS accounts (IMSI, IMEI, IP Address) is stored. OpenBTS currently supports a web interface to this database through a custom C++ cgi module. It is outdated, insecure, and ugly. We are hoping to develop a modern web interface to this system. It is likely to use things like [http://tidy.sourceforge.net/ HTMLTidy] and/or [http://flexigrid.info/ FlexGrid] to provide 

Goal: Implement a replacement to the existing Subscriber Registry Manager CGI script. The core properties of the solution must:
 * Read and Write the Subscriber Registry
 * Securely, with access control to the registry
 * Efficiently, with little load to the server
 * In a modern, beautiful interface
 * That requires a minimum of setup and installation (no full RoR webapps!)

Languages: We hope to minimize the amount of code needed to deploy the solution. As such, our system should rely on simple, standard technologies (this means no custom django webapps). As such, we expect HTML, !JavaScript and other basic web technologies to be the primary languages used for the development, though we're open to other suggestions. 

!Mentor/Contact: Kurtis Heimerl <kurtis.heimerl@rangenetworks.com> and/or David Burgess <david@rangenetworks.com>