Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
initial demo of using jsonp to allow the client.js to get a page from ano #47
initial demo of using jsonp to allow the client.js to get a page from another wiki-server - add alink of the style [[remoteserver:1111|welcome-visitors]] - but you must make sure both servers are running a jsonp enabled wiki
please don't merge into master - this is really just to show you what I'm talking about wrt using JSONP for REST and Fork or remote wiki pages.
alot of client code still points to the wrong url's - show source for eg - a little refactoring to extract out the build URL code should simplify that tho
I like this. I think it would be sweet if a server and the client code it offers could have the freedom to choose either approach:
As you point out, to make this work all servers would need to understand the jsonp protocol. I am a little afraid of jsonp when applied to urls found on the internet. When I've used jsonp I've been in control of all sides of the dialog so I had no issues with eval of untrusted code.
Allen Wirfs-Brock tells me that he has been trying to get browser authors to relax the same-origin policy for application/json text as simply parsing this is much safer than eval of random jsonp expressions. That would be an ideal.
Well, I've talked to some Mozilla people about my idea, but it isn't something I've really pushed on. Also, Crockford said he liked the idea. We'd probably need to get broader community support before the browser implementers would really jump on it.
The basic idea would be to recognize application/json or application/jsonp as distinct mime types in script tags.
So to load a json data file you would say something like:
I have a writeup that I have never broadly circulated that describes this in more detail and address issues like how to make it work with existing jsonp servers that expose files that would normally not parse with JSON.parse.
goodness me, lets see.
non-cross site restricted access to import data from anywhere, into your local browser's persistent datastore.
I would love it, and so would the blackhats - yes, it's much better than the random code injection, it is still random data injection.
so Allen - oh, yes please, making a web data -> DOM mechanism would really improve data application developers lives.
yes, exactly, it'll be safer, but still as unsafe as the rest of the web.
Way too many of us do DSL / data is code like work, so 'no execution of js' does not mean no execution.
Really, it all comes back to the sad fact that web technology has not worked on webs of trust (gpg style), so that I can use type=application/json , and have some assurance (by checking the signature against corruption and that it comes from a source that I have decided to trust) that its data form someone i know.
imo we don't really want to end up with a git-like collaboration method - it leads back to single webmaster syndrome, with the added confusion of many duplicate forks with spelling changes. instead, if I sign your public key as 'i trust you', then your changes could be auto-merged...
I do wish this was rw federated wiki accessible, that way it'd be easer to refactor.
Ward - I'm playing with my static-server implementation, and I think I can make it serve jsonp using mod_include (ie, server side includes).
if thats the case, can we change the definition of a federated server to only talk jsonp? from there, we can later add mirror/read non-federated wiki sources separately..
As I reread your previous comments on this issue I realize I don't completely understand your vision of how computation might be spread over a federation. Would you say more?
After pondering this for a while more I've realized I'm operating from some unstated assumptions. I've imagined a federation of servers creating a medium where higher level structures could emerge. I'd also imagined that this emergent structure would be visible to the web and that this would be a strong motivator for participation. Participation would require provisioning some computational resource which would be under the sole control of the participant. I'm happy to elaborate why I think this to be a strong model. But let me instead echo what I now hear you saying.
You suggest that the federation provide a medium upon which structural subsets are formed as webs of trust. In this there need not be a distinction of client and server. All participants within the web are equals. Admission and expulsion from this web would be handled at a higher level. Jsonp is important to erase the distinction between client and server. A cryptographically sound web of trust makes any security concerns mute. A feature of this form is that I can unilaterally deploy distributed computations to any web where I am trusted.
Let me summarize the distinction as read-only trust v. read-write trust. The read-only model supports innovation because anyone can deploy arbitrary computational resources and use the federation only for retrieving and distributing innert information between them. The read-write model supports innovation because uncommitted computational is contributed to a trusted subset of the federation to be used freely by innovators.
For either model, the participation of static sites is only a boundary case and not likely to inform architectural decision making. I hope I've captured our respective interests. If not, help me understand what I might be missing. As always, I thank you for your participation.
referenced this pull request
Oct 31, 2011
I'm sorry for ignoring this for so long - I need to get some serous foswiki work done before the Foswiki Camp and general assembly at the end of the month - After that, well - I'm somehow expecting that figuring out how to give the girls their first snowy xmas will hit, and then it'll be time to jetlag back to Brisbane :)
I really don't feel I can put in enough time to work though my fuzzy ideas - but while they're drawing on new paper together (collaboration between young twins is fascinating)
my focus on what is currently the static site has more to do with simplifying - if we can use zero code to serve reading, we leverage the nature of http. To add write, all we need to do is write a simple server code to allow PUT (er, or use DAV?)
This then makes me feel that we can focus on the meat of the innovation - the interaction and data dynamics that allow users to innovate.
so when we say 'static' i just think fast and lightweight, not read only.
btw, I keep staring at the elephant - what happens if you have millions of edit events on a page? Especially as iirc, we only get ~5M in the browse datastore.
I was hoping that we would have a federation already, so I could work on our combined, and separate visions, but real life makes quite moments harder :)
mmm, times up.