[Baypiggies] Do you think this would be cool open source?

[nar]

Just my two cents on the RESTful aspect of the project.

REST bugs me. The namespace is arbitrary and conforms to no real  
standards. While it's convenient from a design standpoint, it puts the  
onus on third-party developers to understand what to put in and what  
they get out of it, and that means having to read and understand  
documentation.

If you use SOAP, it certainly incurs more overhead, it's a fat  
protocol -- BUT, the ability to point a SOAP proxy object at some WSDL  
and have it automatically understand what functions are available to  
it and their prototypes makes it so much more attractive to third  
party developers. In terms of security, there's a variety of  
strategies you can utilize that are part of the protocol rather than  
tacking them on at the end by hand.

I think the concept is a great one though! REST definitely is 'easy'  
to write, and probably easier for casual developers to utilize, but I  
prefer SOAP because it's consistent.

-n


On May 7, 2009, at 12:49 PM, Glen Jarvis wrote:

> I've been working on an idea... It's Python and Django based. It's  
> rather a cool idea and I've been working on it for about three  
> months. I'm scrapping my old repository and starting over.
>
> Before I ask my technical questions, let me throw a copy and paste  
> summary of my idea/work out there:
>
> --- start ---
> it really has taken off. I want to start over completely in my  
> repository. This is something I've originally written in Python/ 
> Django.
>
> I wish to disclose my intent to create a web service for a  
> programable (Quick Response) QR barcode. The QR Barcode patent is  
> owned but not exercised by Denso Wave.
>
> These QR codes can store numeric, alphanumeric, binary,  URL,  
> binary, address cards, SMS and other types of storage. They are,  
> however, limited to a finite amount of data and can only store the  
> types of data already predefined in the barcode specification.
>
> Additionally, each time a different type of data is stored in the  
> barcode, the barcode that is generated is different. This does not  
> allow for a one-stop posting of a barcode. For example, if a  
> specifically encoded QR code is printed on a T-shirt, then if the  
> content of the barcode needs to change, the barcode needs to be  
> reprinted. It is not feasible, then, to dynamically change the  
> content of the barcode without having to reprint the barcode.
>
> I propose that a single barcode per user or entity (e.g., for John  
> Doe to have professionally printed on his t-shirt) is created. The  
> format of this barcode is URL and points to a specific web address.  
> Additional parameters are encoded in the URL to indicate the entity  
> (e.g., John's T-shirt).
>
> Then, the web server can return any amount of data (limited only by  
> the practicality of transmitting that data). Additionally, since the  
> Web server can run programs, the function of already printed code  
> can be extended at any time by the addition of a new program on the  
> web server.
>
> An example of the data stored in this 'fixed' or 'programmable'  
> barcode could be (but is not limited to) as follows:
>    http://glenjarvis.com/scan?id=34&token=4343d (currently not a  
> valid url)
>
>
> The webserver, in this example at glenjarvis.com, would receive a  
> scan with id of 34. The barcode object with that id has a dynamic  
> program associated with it (e.g., return a random Irish Limerick).  
> Then, whenever barcodes are scanned (for example, with a mobile  
> phone, the user is redirected to the URL, and an Irish Limerick is  
> returned to this user. The programs added to this code can be  
> scavenger hunts, physical games (like tag: last barcode scanned  
> wins), etc.
> --- end ---
>
> This worked very well conceptually... In fact, I separated  
> everything so that every barcode had a 'program' associated with it.  
> The program was actually a string to dynamically call a verified  
> program (each program is a django app named with the id of that  
> 'program' in the database).
>
> Because QR codes are so popular in the rest of the world, I imaged  
> that we're only limited by the creativity of people out there -- for  
> example, if someone from BayPIGgies is interested in creating a  
> 'program' for this platform, they only need to write it.
>
> As I progressed, and reality came from the idea, it was clear that:
> 1) All new programs had to be 'registered' manually (that is,  
> instructions are given and a sandbox is given to develop, but the  
> production system has to be very carefully controlled for security).
>
> 2) Django is so mono-lithic.. but, we want to launch external  
> programs. The internal django app mentioned above handles the basic  
> call (like a poll thread handles all incoming calls). But, the work  
> is done by external systems. And, this came down to RESTful ideas.
>
> But, that's where things kinda smoldered for a while. Can a fully  
> RESTful system be created where program execution (even if through a  
> URL) is done, passing a small set of JSON data. And, an API of  
> certain authenticated calls is given to that program for use...
>
> I've never done any facebook apps or myspace or other networking,  
> but is this how they work?  How does the security model work? Is  
> REST the best model?
>
> Any thoughts you have would be appreciated. This is more stream of  
> conscious discussion as I consider these past few hurdles.
>
>
> Warmest Regards,
>
>
>
> Glen Jarvis
> _______________________________________________
> Baypiggies mailing list
> Baypiggies at python.org
> To change your subscription options or unsubscribe:
> http://mail.python.org/mailman/listinfo/baypiggies

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/baypiggies/attachments/20090507/ea843daf/attachment-0001.htm>