Topic: A little less conversation, a little more action. (XML-Request)

This was briefly addressed in the Flash forum, but I think it has a place in the Software forum as well.

I do not own a Chumby (sadface) but, I would be interested in developing an XML-Request format, and proxy, not just for bypassing the crossdomain.xml limitation, but also as a method of providing a universal way of sending and recieving data on the Chumby, both for Flash applications and for homebrew applications as well.

The format would (of course) be built on standard HTTP, or HTTPS for sensitive data, such as pulling gmail RSS feeds, banking/investment data etc.

Although the XML-Request format would be the cornerstone of our project, I think as a demonstation application, we should also develop a Flash widget that uses our API, and a web application which provides content for our example application.

What this all boils down to, is that I wish to create an XML Request format that is capable of transferring data both to and from the Chumby, and create a web application (probably in JSP/ASP.NET - something that supports JIT complilation to alleviate the load that PHP/ASP/RoR would put on the server) that is capable of feeding information to the Chumby in a STANDARD FORMAT.

An extension of this could also be a hosted web service (I'm happy to fund this) that enables developers to host their XML-Request server application logic on our servers, so that they don't need to own their own infastructure to provide content-driven widgets to the Chumby.

If anyone has any questions, feel free to post here. I'd like to work with a close-knit team of developers to help male this happen. It has the potential to open up avenues, not just for the Chumby, but for other consumer embedded devices (maybe even mobile phones) that require a standard request API.

Comments and (constructive) critisism most welcome.

Re: A little less conversation, a little more action. (XML-Request)

id be happy to help host.

need upload space for the forums or a chumby blog? right here then
http://www.nophus.com/useru
username is chumby
password is chumby

Re: A little less conversation, a little more action. (XML-Request)

I own a web hosting company, so I should be able to handle that, thanks for the offer though.

What I'm really looking for here are people who want to help develop, preferably people who have some sort of experience with server-side Java.

Re: A little less conversation, a little more action. (XML-Request)

I really don't think you want to be that complicated.  What you want to do is hit a proxy and have it generate a response that's identical to the one the actual site would have come back with.

So, why can't it be as simple as:

http://proxy.example.com?url=http%3A%2f%2fsome%2eother%2eexample%2ecom&cache=15

So you just pass the escaped url of the site you want to hit, and an optional "cache" parameter to set how long you want it cached in the proxy (for photos, etc, there's little reason to hit the original site again).

There isn't much this thing needs to do, so layering XML all over it seems like overkill.

Re: A little less conversation, a little more action. (XML-Request)

I agree that things should be more complicated that they need to, and I would add that there are already standard that could be levereged:

- for proxy/crossdomain.xml issues: some of Macromedia/Adobe Flash-related products already offer proxy functionalities. Also I am sure there are open source implementations that already provide that. A standard "blind" proxy/tunnel would solve the problems but you may want to have a way to only proxy sites you trust (maybe, maybe not).

- there is a standard (Flash remoting) to exchange information and execute remote procedure calls from Flash. FlashLite 2 should support that and there are plenty of implementations of the serverside code for multiple languages.

- there is a stanard "Chumby" XML format to pass configuration parameters to Chumby apps (and maybe the other way around ?). It would be good if some documentation about this was made available so that developers can start playing with it. Even if it's preliminary and could change later (hopefully not too much) making it available now would help developers understand what is already done (or planned) and what still need to be done.

Re: A little less conversation, a little more action. (XML-Request)

The chumby currently uses a "FlashVars"-type approach to get user-defined parameters into the widget.  This means that you get a bunch of variables already defined at the top level of the widget movie, plus some extra ones that are chumby-specific, like some basic info about the user, the id of the chumby etc.

For instance, the current "Horoscope" widget launches with a variable "sign" already set.

This has the advantage that its something already understood by Flash developers, and will also work in a Flash simulator of the chumby.  Anything more complicated would eliminate the ability to use a stock Flash player to debug a widget.  What you're *supposed* to do is pass in just enough information to have the widget get more from elsewhere.  Thus in a weather widget, you would not pass in the actual weather info in a big block of XML, but rather, say, the zipcode, which is then used to fetch the info from some other external service using XML.load().

There's nothing so say that a value can't be XML, but like FlashVars it would have to be an encoded string that would be passed to the XML object constructor to be parsed.  I don't recommend it, since unlike XML coming in using load(), this would be parsed synchronously, which is probably bad for large XML and such a lightweight processor.

7 (edited by silent_guardian 2006-09-07 04:37:28)

Re: A little less conversation, a little more action. (XML-Request)

I'm not familiar with Flash Remoting - does this require Flash Live Communications Server to operate? If so, wouldn't it be better for widget developers to have their own XML transaction format?

I realise you could use a simple proxy, but a simple proxy doesn't allow for aggregation of data from remote sources, and it doesn't offer a way for Flash developers to easily publish their content-driven widgets without having to provide their own hosting - it's also stupid to use that bandwidth twice. (I mentioned content aggregation before, so I'll shut the hell up about it. wink

If there is already a standard Chumby XML format, I'd love to see it! This would open up a lot of possibilities for widget developers who want to use data in their applications now.

Hell, it doesnt' even have to be XML, it can be parsed using CSV if you really want, it just seems that XML is the in thing right now, like the words "lifehack" and "blogosphere". /me shudders. (All behold Chumby 2.0? wink)

Where I would like to be in a month's time, is having a widget developed that informs you, in semi-realtime, when your friends MySpace/LiveJournal blogs are updated, or any RSS feed changes. This could serve as an example for other widget developers who want to use data in their applications, and could serve as a pratical example and implimentation of the Chumby XML format.

Comments?

EDIT: Changed wording. I kinda got sidetracked there wink