I think we're agreeing that developers can do whatever computation
they want on an XWT client. As I understand it, there are two ways:
XWT UI descriptions can include Javascript. Javascript is
terrific. It's well known by lots of people, and easy to learn for
others. However, there's no perfect language for all purposes.
Javascript was specifically designed for short scripts. As a
consequence:
It doesn't have the programming-in-the-large support
needed for large projects involving many people or organizations, or
for modeling complex problems.
It is very difficult to build an implementation in which it
executes very efficiently (e.g., on the scale of inner loops of a
graphics app).
None of this is a problem for XWT's stated design space --
UIs to applications that execute on the other end of a network
connection. But suppose you do want to something fast and complex on the
client? This brings us to...
You can write a dedicated client app in C++ or some such, get it to the user's
machine, and then communicate with it through XML-RPC. I can imagine
other similar communications through the browser. This can be nice,
because each part of the job is done with a tool that is designed for
that domain. Different people with entirely different skill sets can work on
the different parts. However, whenever you mix technologies and try
to have tight communication between them, there can sometimes be
problems. I'm not sure that this scenario is really the best way to
deliver on the benefits that lead us to Web-based apps in the first
place (see the start of my original posting, vs. Curl).
I also agree with Adam that Surge isn't as approachable as it could
be. If a Javascript-based UI-architecture starts to slip as the
complexity or responsiveness requirements go up, you would think
that it should be possible to approach things the other way and use
just the parts of Surge you need for doing simple UI stuff? Surge
was indeed designed to let simple things be simple. For
example, there's an integrated layout and formatting engine that makes
it easy to declare how stuff should be organized such that you don't
have to write code to handle resizing of windows while avoiding
horizontal scroll bars. And you don't have to include type
definitions, or write procedure or class definitions.
But as a practical matter, there is a lot there, and it is
different enough that I can understand how a time-pressed developer
wouldn't want to learn something new. And the "gentle slope" approach
isn't perfect. For example, I'd rather see undeclared numbers use
decimal or bignuminteger representations
than fixed size representations. (Although Javascript has the same
problem. By the way, Adam, where did you count 18 int
types? I count six with two more pseudonyms. Java has five, C eight,
and C# nine.) Anyway, the point is that Surge is really more
optimized right now more for enterprise-level programmers with big
problems then for mass adoption by designers.
So where's the dividing line today? The XWT FAQ mentions that
interactive games are probably not appropriate to a Javascript-based
UI-server approach. Anything else? Right now, Curl seems to be
resonating most with people developing enterprise stuff with a high
degree of custom business logic, tight response times, high
interactivity, and changing requirements. My personal feeling is that
there isn't much like this on the consumer web because there hasn't
been a reliable way to develop and deliver it before. The space of
simple applications hasn't yet been exhausted, and for these,
UI-servers are plenty good enough. Comments?
Neat stuff. I do want to straighten some things out wrt Curl:
"1.8 What other technologies are similar to XWT?
CURL Surge is a similar framework, although it requires per-use licensing fees and is a bit baroque."
Actually, Curl offers a variety of
licensing arrangements, including per user, per site, etc.
I think XWT and Surge both aim to combine the benefits of native applications:
responsiveness, interactivity, and so forth
with those of server based software:
administration: install, update, secure data storage
"Browser as user environment"
security for user machine and for site
However, XWT focuses on what I might call a UI server approach. It
can do more, but it is optimized for working only with an
application's user interface while the application computations take
place on the server. This specialization is consistent with the the
separation of UI vs other design concerns, and has a lot of good
characteristics, such as in the size of the initial platform download,
potentially the size of the initial applet download, and the scope of
learning required from developers.
Surge can be used in exactly the same way, but it is designed to
handle more complicated application logic right on the client. You
can make any separation you want (between client & server; between
data, logic, and presentation; between different modules or levels of
any of these), but you can also combine them within the same
environment when appropriate. Technically, this provides a fuller
range of application richness and deployment scalability, but there
are other concerns such as learning, or how universally the platform
is available.
In light of this difference in emphasis, I'm wondering which parts
of Surge the author finds baroque. Let us know, Adam.
Another slashdotter also commented on the XWT FAQ's comments on
source code vs. binary. I don't know how it works out in XWT, but
Curl applets are in source so that they can be compiled to very fast
native instructions on the platform they'll run on. Specific client
resources can be utilized (e.g., for graphics), which a byte-code-JIT
would have a hard time doing unless the byte-code included some pretty
darn high-level instructions. Also, source code is much more compact
than low-level machine or JVM instructions. Since compilation is much
faster than the network, that gives a quicker total time from
http-request to execution. If people are worried about protecting
their applet code, they can obscure, encode, and compress it. Surge
has a pre-parsed delivery option for code that does this.
For what it's worth (see sig), I see it like this:
There's no charge until something is commercially
deployed. And then the charge is proportional to how much it's
actually used.
"The Man" likes this because he's already paying per use: server
usage, pipes, etc. If he can pay less per use -- sending some of the
difference to Curl -- that's cool, too.
Even so, there are other plans such as volume discounts for the
big, or first X gigs free for the small. I'd rather see Curl post all
this on the site, but I suppose requiring direct personal
communication at this stage cuts down on people misquoting or making
stuff up.
It is true that with or without Curl technology, you can
hit reload a zillion times and cost some corporation an extra nickel
or two. One change with Curl is that the additional cost might be
less.
Logging of usage information includes nothing that isn't in server
logs. Actually, it's less: no identifying personal information at
all, such as machine ID. In general, nothing about the user is
"licensed" in any way, only the content provider.
There's no charge for development or end user seats. (OK, so the
Beta development environment is about what you'd expect from people
who use Linux in development. Yes, we run our stuff on Linux
internally, but commercial quality will take more work. Anyway, the
point is that we don't charge for the IDE, compiler or runtime.)
The legal mumbo-jumbo on the site serves some of the same purpose
as the Free Software Foundation's protection of GNU stuff -- to make
it (at least a little) harder for bad guys to take control of the
technology and restrict it in a less nice way.
Achieving critical mass for plug-in deployment and content
creation is hard, but there are other more channelled ways to go. The
pricing should "keep out of the way" of both.
I give a lot of credit to DARPA and investors for supporting what
I feel is pretty progressive approach. Of course, no one knows how
nice it will turn out for everybody. But I'd like to think it's
starting off as practical and reasonable. I'm sure someone will tell
me where I'm thinking wrongly about this...
I didn't follow this. Could you explain? (I work for Curl, so I'd like to know.)
There are a couple of things going on here.
First, one might deliver in Curl for functionality, development&maintenance, or bandwidth. Sometimes these are tradeoffs. More functionality (e.g., interaction on the client) MAY mean a bigger "program". Reducing graphics transfers by switching from a server-built image to procedural graphics generated on the client MAY increase development&maintenance costs. However, there are some pure win/win situations, too.
HTML/XML is pretty verbose compared with Curl, so that alone saves a bit in both bandwidth and development&maintenance. Of course, that's not enough by itself and I wouldn't want people writing Web pages in Perl! It's just one thing that enters into it.
More important, is basic abstraction. If you use something twice, you can define it once and reference it many times. When the abstractions take parameters (i.e., are procedures), you really win on both bandwidth and development&maintenance.
The biggest win, though, comes when there are multiple interactions. Build a layout and interaction mechanism once and use it in a bunch-o-projects. Once the client has it cached, they don't need to get it again. Then just send the "data" that changes with each interaction. No need to resend what hasn't changed and no need to flicker the user's screen. Smaller, faster, better. Yes, this part is the same idea as XML, and the transfered "data" might very well be encoded in XML. You could think of Curl technology as a way to deploy a specialized XML viewer.
By combining these (including the procedural graphics), we're seeing order of magnitude bandwidth decreases. Since big sites pay for bandwidth, the decreases more than offset the cost of a commercial use of the technology. The snapier and more fun interactions for the user are a bonus.
Slashdot Mirror
I think we're agreeing that developers can do whatever computation they want on an XWT client. As I understand it, there are two ways:
- It doesn't have the programming-in-the-large support
needed for large projects involving many people or organizations, or
for modeling complex problems.
- It is very difficult to build an implementation in which it
executes very efficiently (e.g., on the scale of inner loops of a
graphics app).
None of this is a problem for XWT's stated design space -- UIs to applications that execute on the other end of a network connection. But suppose you do want to something fast and complex on the client? This brings us to...I also agree with Adam that Surge isn't as approachable as it could be. If a Javascript-based UI-architecture starts to slip as the complexity or responsiveness requirements go up, you would think that it should be possible to approach things the other way and use just the parts of Surge you need for doing simple UI stuff? Surge was indeed designed to let simple things be simple. For example, there's an integrated layout and formatting engine that makes it easy to declare how stuff should be organized such that you don't have to write code to handle resizing of windows while avoiding horizontal scroll bars. And you don't have to include type definitions, or write procedure or class definitions.
But as a practical matter, there is a lot there, and it is different enough that I can understand how a time-pressed developer wouldn't want to learn something new. And the "gentle slope" approach isn't perfect. For example, I'd rather see undeclared numbers use decimal or bignum integer representations than fixed size representations. (Although Javascript has the same problem. By the way, Adam, where did you count 18 int types? I count six with two more pseudonyms. Java has five, C eight, and C# nine.) Anyway, the point is that Surge is really more optimized right now more for enterprise-level programmers with big problems then for mass adoption by designers.
So where's the dividing line today? The XWT FAQ mentions that interactive games are probably not appropriate to a Javascript-based UI-server approach. Anything else? Right now, Curl seems to be resonating most with people developing enterprise stuff with a high degree of custom business logic, tight response times, high interactivity, and changing requirements. My personal feeling is that there isn't much like this on the consumer web because there hasn't been a reliable way to develop and deliver it before. The space of simple applications hasn't yet been exhausted, and for these, UI-servers are plenty good enough. Comments?
"1.8 What other technologies are similar to XWT?
CURL Surge is a similar framework, although it requires per-use licensing fees and is a bit baroque."
Actually, Curl offers a variety of licensing arrangements, including per user, per site, etc.
I think XWT and Surge both aim to combine the benefits of native applications:
responsiveness, interactivity, and so forth
with those of server based software:
administration: install, update, secure data storage
"Browser as user environment"
security for user machine and for site
However, XWT focuses on what I might call a UI server approach. It can do more, but it is optimized for working only with an application's user interface while the application computations take place on the server. This specialization is consistent with the the separation of UI vs other design concerns, and has a lot of good characteristics, such as in the size of the initial platform download, potentially the size of the initial applet download, and the scope of learning required from developers.
Surge can be used in exactly the same way, but it is designed to handle more complicated application logic right on the client. You can make any separation you want (between client & server; between data, logic, and presentation; between different modules or levels of any of these), but you can also combine them within the same environment when appropriate. Technically, this provides a fuller range of application richness and deployment scalability, but there are other concerns such as learning, or how universally the platform is available.
In light of this difference in emphasis, I'm wondering which parts of Surge the author finds baroque. Let us know, Adam.
Another slashdotter also commented on the XWT FAQ's comments on source code vs. binary. I don't know how it works out in XWT, but Curl applets are in source so that they can be compiled to very fast native instructions on the platform they'll run on. Specific client resources can be utilized (e.g., for graphics), which a byte-code-JIT would have a hard time doing unless the byte-code included some pretty darn high-level instructions. Also, source code is much more compact than low-level machine or JVM instructions. Since compilation is much faster than the network, that gives a quicker total time from http-request to execution. If people are worried about protecting their applet code, they can obscure, encode, and compress it. Surge has a pre-parsed delivery option for code that does this.
There's no charge until something is commercially deployed. And then the charge is proportional to how much it's actually used.
"The Man" likes this because he's already paying per use: server usage, pipes, etc. If he can pay less per use -- sending some of the difference to Curl -- that's cool, too.
Even so, there are other plans such as volume discounts for the big, or first X gigs free for the small. I'd rather see Curl post all this on the site, but I suppose requiring direct personal communication at this stage cuts down on people misquoting or making stuff up.
It is true that with or without Curl technology, you can hit reload a zillion times and cost some corporation an extra nickel or two. One change with Curl is that the additional cost might be less.
Logging of usage information includes nothing that isn't in server logs. Actually, it's less: no identifying personal information at all, such as machine ID. In general, nothing about the user is "licensed" in any way, only the content provider.
There's no charge for development or end user seats. (OK, so the Beta development environment is about what you'd expect from people who use Linux in development. Yes, we run our stuff on Linux internally, but commercial quality will take more work. Anyway, the point is that we don't charge for the IDE, compiler or runtime.)
The legal mumbo-jumbo on the site serves some of the same purpose as the Free Software Foundation's protection of GNU stuff -- to make it (at least a little) harder for bad guys to take control of the technology and restrict it in a less nice way.
Achieving critical mass for plug-in deployment and content creation is hard, but there are other more channelled ways to go. The pricing should "keep out of the way" of both.
I give a lot of credit to DARPA and investors for supporting what I feel is pretty progressive approach. Of course, no one knows how nice it will turn out for everybody. But I'd like to think it's starting off as practical and reasonable. I'm sure someone will tell me where I'm thinking wrongly about this...
I didn't follow this. Could you explain? (I work for Curl, so I'd like to know.) There are a couple of things going on here. First, one might deliver in Curl for functionality, development&maintenance, or bandwidth. Sometimes these are tradeoffs. More functionality (e.g., interaction on the client) MAY mean a bigger "program". Reducing graphics transfers by switching from a server-built image to procedural graphics generated on the client MAY increase development&maintenance costs. However, there are some pure win/win situations, too. HTML/XML is pretty verbose compared with Curl, so that alone saves a bit in both bandwidth and development&maintenance. Of course, that's not enough by itself and I wouldn't want people writing Web pages in Perl! It's just one thing that enters into it. More important, is basic abstraction. If you use something twice, you can define it once and reference it many times. When the abstractions take parameters (i.e., are procedures), you really win on both bandwidth and development&maintenance. The biggest win, though, comes when there are multiple interactions. Build a layout and interaction mechanism once and use it in a bunch-o-projects. Once the client has it cached, they don't need to get it again. Then just send the "data" that changes with each interaction. No need to resend what hasn't changed and no need to flicker the user's screen. Smaller, faster, better. Yes, this part is the same idea as XML, and the transfered "data" might very well be encoded in XML. You could think of Curl technology as a way to deploy a specialized XML viewer. By combining these (including the procedural graphics), we're seeing order of magnitude bandwidth decreases. Since big sites pay for bandwidth, the decreases more than offset the cost of a commercial use of the technology. The snapier and more fun interactions for the user are a bonus.