Proposed Webservice - Proximity Web Control

Proximity is a linux-based daemon that performs commands or calls applications based on events from WIFI, Bluetooth, and GPS. These events are encoded in an XML file. I propose that a webservice and a web front-end be developed to edit this XML file online and allow for the client FE/OS to download this edited XML file.

More information about the Proximity app can be found here.

Proposed Client Functionality
The client must be able to download a full XML file from the server with no modifications needed.

Proposed Web Functionality
The web functionality will be split between two parts: web front-end and webservice.

• Web Front-End - Must be able to edit this XML file using an easy to use online GUI and be able to fully edit all parts of this XML file without lacking any features. This GUI should include dropdowns/options for easy to use instructions and commands that "normal" people may not understand. For instance, instead of calling rsync directly (bin="/usr/bin/rsync"), the selection would have the option for (copy and paste, sync, or some other easy to understand command).
• Webservice - The webservice must allow the web front-end to get at any part of the XML file required and also allow full updating of the document as well. It would be best if the webservice did the work of getting the right data and sending it on then rather sending the whole XML document for the web front-end for processing.

Proposed Plan of Action

• Use ASP.net as the web front-end
• use a mySQL table to hold the index of the XML file, the UID of the user, and using mySQL longtext format to store the entire XML doc inside a cell of the table

Current Process = Currently deciding on exact functions, return datatypes, and waiting on creation of SVN directory to upload to

While this is a frontend to the OpenICE Proximity, it should be able to be used as a generic sync settings (and more) service for all frontends/platforms. I just wanted to make that clear.

will this be a RESTful service?

Quote:

---

Originally Posted by kev000

will this be a RESTful service?

---

It can be for certain parts or this can be designed for 100% compliance. Ill demonstrate below.

Client

When the client requests the XML, the only data required is the user ID associated with that XML doc so the correct XML can be returned. Hence a simple RESTful get is all that is required.

/webservices.asmx/GetXML?uid=XXXX

This will return the XML doc then.


Web Front-end

This is more difficult. While getting the data can be RESTful, updating the data can either be done with SOAP for sending complex data (a whole event with commands and args in XML format) or sending requests one at a time for RESTful.

RESTful Pros

• More simplier to code and execute

RESTful Cons

• Requires creating more functions meaning possible more dev time
• Requires changing the XML doc directly whenever changes are made on the front-end. There will be no option to "cancel changes". Also, requiring function calls for every action could add lag.

SOAP Pros

• Can send complex data types and thus update more records with less function calls
• Can update at the end and thus allow canceling edits and no lag when using the GUI

SOAP Cons

• Complex SOAP calls are cumbersom and quite difficult
• Other clients may not be able to call these functions (phones, other devices, flash, etc?)

However, since ASP.net allows the same function to be called with both SOAP and HTML GET (RESTful compliant), this allows the best of both worlds as we could incorporate both schemes and see what would be suited in the final build.

Quote:

---

Originally Posted by kev000

While this is a frontend to the OpenICE Proximity, it should be able to be used as a generic sync settings (and more) service for all frontends/platforms. I just wanted to make that clear.

---

Would Proximity be able to run on any major Linux distro such as Ubuntu?

Quote:

---

Originally Posted by Nextabyte_Matt

Would Proximity be able to run on any major Linux distro such as Ubuntu?

---

yes.

May I propose that we make the web piece/pieces a Tomcat deployable webapp/s?

Although I'm not a tomcat programmer I work with such apps frequently at work and its always a pleasure because:

* Tomcat is a breeze to install. Anybody can do it. This is handy for testing
* Tomcat webapps can be fully self-contained. Makes for easy backups, restores, re-installs, upgrades.
* Tomcat webapps scale well in a web service provider environment. One server, many servers, thus handling unlimited load.
* They're written in Java, so it's an open language that anybody can contribute to, unlike the Microsoft equivelant.

references:
http://tomcat.apache.org/


/$0.02 =)

These web services will run on Apache2 web servers or MS IIS Web servers. The only requirement is mono or .NET runtimes. I'm not sure what makes Tomcat different from vanilla Apache, but it may be possible to run the web services on that as well.