"inputs" is actually a macro, so changing "inputs" will only affect code that you load after the change. (A macro works by transforming the code it is applied to, so after the code has been transformed the macro isn't used anymore).
For your first question, can you post your definition that isn't working for you?
The easiest? To serve HTTPS web pages run a web server which supports SSL such as nginx, lighttpd, or Apache in front of Arc; and to make HTTPS requests from Arc run a web client program which supports SSL such as wget or curl.
If you want to make an AJAX call from your browser to fetch some HTML from your server and put that data inside a div, you don't need to use JSON for that. Just have your Arc op return the HTML.
Untested, so I apologize for any mistakes:
(defop grabdata req
(pr "This is my <i>HTML</i> content!"))
and, in the browser, using for example JQuery (http://jquery.com/) as a convenient way to make the AJAX call:
$.get("http://yourserver.com/grabdata", function (data) {
$('#your_div').html(data);
});
replaces the contents of the div that has the id "your_div" with the HTML content returned by grabdata.
Presumably forward slashes in URL's would need to be changed to backslashes to store the library file in the lib directory with the corresponding path. (MzScheme has some platform-independent path manipulation procedures that could be used if they turn out to be convenient).
Also, is there a version of wget for Windows? What are the instructions for installing it that should be added to the lib documentation? Would the lib code need to invoke wget differently?
There may be some other things too, those are the ones that occur to me off the top of my head.
Having the tests for two extensions return true for an input can be useful, for example if you have a specific case and a general case. By loading the specific extension after the general extension, the specific one will override the general one.
and the browser doesn't need to download it again if it is already in the browser's cache. This was one of my inspirations as I've been doing a lot of browser Javascript lately. The addition I made was to avoid getting the latest version automatically, as I imagined people might be nervous about that. (I know I would be. After all, Javascript in the browser runs in a sandbox, but Arc on your server can call (system "rm -rf /") etc...)
Thanks for the hint, I've now got a simple version where it takes the who-called-who from recording invocations. I'm currently working on sample call data, but profiling would also be interesting.
The first thing that comes to my mind is more of a philosophy rather than a feature. One of the Agile principles is don't implement things until you need them... no speculative development: the tenth principle down in http://agilemanifesto.org/principles.html reads "Simplicity--the art of maximizing the amount
of work not done--is essential." The XP process implements this with its rule that you only write code to implement the current iteration, no writing code to implement features that you "know" will be coming in future iterations.
When I first read the Arc web server code (srv.arc) I was astonished at how simple the code was.
srv.arc doesn't do everything I want, but other web frameworks don't do everything I want either. And I've found it much easier to hack srv.arc to do what I want, precisely because it isn't massively bloated with "framework" stuff, stuff that we imagine we'd need to write a web application, but we don't actually need or it turns out we need in some other way when we actually write an application.
Showing off how easy srv.arc is to hack is a great example of the Agile simplicity principle. Need to get a servlet to output a custom header? Plow through the documentation to find the right addHeader() invocation and what object to call it on. Need to get Arc to output a custom header? (prn "My-header: foo")
This is interesting, I had been thinking only of how the core language might appeal to an agile mindset but it's true that the libraries have a lot to offer as well.
Hmm, because you mentioned verisign I jumped to the conclusion that you were talking about HTTPS, but by "data security" were instead talking about keeping people from breaking into your server? You wouldn't need HTTPS for that... with Slicehost or Linode you'll be using ssh to login to your server, and ssh is encrypted and secure.
You were correct. I was looking to log into my web-app using https. And in retrospect (you're right again) I could just log into the secure server and show the work that way too. All that being said I still would like to learn setting up https, even for the sake of learning (and I'm sure someday I will need to).
