Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror

Comment Re:Finally! (Score 4, Informative) 151

That's not planned for the moment, but with PreferenceStats.jsm (currently in Firefox Nightly), it is already possible to write an add-on that does monitors each tab. Firefox doesn't have a feature for stopping all scripts in a page yet (that's https://bugzilla.mozilla.org/s..., if you're curious), but reloading the tab without scripts (or other features) shouldn't be too hard.

Comment Re:threads (Score 1) 253

Am I understanding correctly that you have reimplemented threads on an application level, instead of the OS level? So your application's threads (fibers, whatever) can be pre-empted by the OS, because the OS doesn't care about your scheduler when it's handling its own processes?

This is absolutely correct. And, if you check, this is what any system that wants to be able to manage tens of thousands of threads does (not necessarily with the exact same techniques). Including all major databases, all large scale virtual machines, etc. Recent versions of MacOS X even provide system libraries to simplify the implementation of such user-level threading (under the name of Grand Central Dispatch).

Am I also understanding correctly that there's no priority system for your threading implementation?

Actually, there is one. It is just not exported to userland yet.

Comment Re:How is it different from, say, Wicket or ZK? (Score 2) 253

Ah, I think I finally understand your point. It is about compatibility, not about paradigm, is it?

If so, you may be happy to learn that the low-level layers of Opa can already access other databases. The feature is not accessible at high-level yet because we are going to make a number of breaking changes before long, but eventually, we do intend to give access to most mainstream databases. Would this solve your problem?

Comment Re:yeah let's build a castle on a base of sand (Score 1) 253

because html, javascript, and browsers are soooo robust and versatile

Good point. We had really hard times tweaking the compiler until it produced JavaScript that worked on all browsers (note: in our books, IE7 is not a browser), or html that worked in all browsers, and with linking with all mainstream JS libraries (note: thanks Facebook for the nice code provided, that explicitly depends on server misconfigurations and/or browser bugs and suddenly stops working when confronted to a standards-compliant web browser and a well-configured server), and with getting our Comet to work with all the different possible interpretations of "asynchronous".

But that is not the point. The point is that this is a problem that *every* non-trivial web application needs to face. The point is that we faced it and we beat it, so that Opa developers do not need to. Should a new browser version arise and cause new incompatibilities, *we* will be the ones doing the heavy debugging until we can produce a new version of the compiler and runtime that lets developers forget about the incompatibilities.

So yes, these brittle bases made our work difficult (and interesting :) ). But they also constitute an important part of the interest of Opa.

Caveat I'm part of the Opa team. Well, worse than that, I am the architect-in-chief.

Comment Re:Integrating everything into one thing? (Score 1) 253

The problem is that you've just created a monolithic application that ties one single database to one single front-end. What happens when you want to swap out databases?[...] It's just another language that corporate developers not only need to learn, but need to sell to management [...] But as it is, it's an interesting idea, nothing more - I'd never let it in my development shop, and even if I did, the architectural committee would hang me out to dry.

I can understand the issue. Would this calm your concerns if I told you that

  • on the Opa git, there is an Opa version for Windows – it's not quite ready for prime-time, but it's there;
  • Opa is designed to be able to link with other server-side technologies – for the moment, OCaml and C, other technologies will arrive in time;
  • at low-level, the Opa database can access other, mainstream, database – the feature is not quite exported at high-level yet, because we are not quite satisfied with it yet, but in time, it will;
  • and of course, there is always the option of modularizing your code through the use of web services, which is a nice way of allowing [hot]swapping of components.

And "compiling to JavaScript" is just ignorant - there's no such thing. Maybe the author means "translating to JavaScript"?

Of course, what do I know about compilation? I only have a PhD on the topic and 9 years of professional experience.

Comment Re:needs time (Score 1) 253

Interesting question. Let's forget about the framework for the moment and concentrate on what the compiler should do:
  • analyze statically the whole code and determine what goes on the client and what goes on the server (I tend to believe that this is not feasible with a dynamic language, but of course, feel free to prove me wrong);
  • compile client-side code to JavaScript or to code that can be interpreted by a JS-based VM (lots of work, but no theoretical barrier, emscripten can even make your life somewhat easier at least for C++);
  • inject Ajax entry points on the server (no real problem there);
  • inject Comet re-entry points on the server (requires a server-side language that supports either CPS or tens of thousands of lightweight non-blocking threads – theoretically possible with custom implementation of the languages).

That's without security or distribution, without database, without a syntax for css or html, but it looks somewhat possible for some languages, with considerable effort. Say, if you attempt to do this, don't hesitate to ping me, it might be interesting.

Slashdot Top Deals

Where there's a will, there's a relative.

Working...