Re: [xwt-users]Shouldn't the server be as easy.

> While I certainly recognize the huge benefits for
> something like
> this for the client side, I personally don't see any
> benefit in
> replicating j2ee/.Net/Zope (or even ASP/PHP,
> although I don't think
> these are in the same ballpark) just so you can use
> JavaScript. 

 I am not really planning to replicate any of these
things. j2ee runs a broad gamut of technologies none
of which are simple or easy to do (not especially
hard, just not as easy as they should be). I can't say
much about .Net I have never used it but it may be
something similar, I just don't know. Zope is an full
blown Http application server with plenty of nice
server side and client side technologies. ASP/PHP are
client side and don't really apply.

Zope is probably the closest to Polar, though Polar
addresses a much smaller area then Zope addresses.
That being the case I expect polar to be easier to
adopt, it helps that it will be written in a massivly
overhyped language (java).

> Using
> VisualStudio.Net or Eclipse you can already do easy
> server-side stuff
> (check out http://ws.apache.org/xmlrpc/server.html)
> with auto-completion,
> auto indenting, etc, and if you really want to use
> javascript, I think
> .Net will allow you to do so.

  With the client side stuff my main goal is not to
replace Eclipse or VisualStudio. I just need a
distributed client that is easy to deploy and can
easily manipulate the server I am planning. This
currently doesn't exist and it looks like I can save
myself allot of hassle by using XWT. I will try to put
all the features you mention in the client but they
are incidental and not core to the needs of the
client. 
  
  I actually use Eclipse in my day to day life and its
very nice, but once again I am not trying to replace
VisualStudio or Eclipse for what they do. Nor am I
enamored of javascript, it has quite a few failings
and is only useful as a scripting language in a
carefully constructed environment. In this regard it
does very well. The fact that there is already an
implementation out there for javascript in java just
makes the decision to use it easier.

 But we are straying from the main argument. Let me
give you a little user story and maybe that will help
you to understand my goal. I will also provide a
similar one for Eclipse so the differences may be
compared.

With Polar --

 The user request a change in a search/query in the
companies main business application, perhaps he wishes
for his query to return active as well as inactive
contracts instead of just the active ones it now
returns. The change is reviewed and accepted by the
developers and scheduled for one of the devs.

 The developer assigned pops over to the url that
launches the IDE for the development server. He finds
the service he wishes to modify in some type of tree
select that lists all services on that server. When he
selects it the source for that service appears in the
editing area (There would probably be some locking
mechanism if another dev was editing it, but thats not
relevant). He then proceeds to modify the script
slightly and save it. When he saves it, it is written
to the development server that served the IDE he is
using. Once saved, it is immediately available. He
tests it out on the client (XWT, PHP, whatever) and
sees  that it works. 

 He goes back to his IDE and schedules the script to
be moved to the QA environment. The testers test it
and certify that it works. He makes a request to his
lead to have it moved to production. His lead moves
the script to production with a click of the IDE and
its all done.


Eclipse

 The user request a change in a returned query,
perhaps he wishes for his query to return active as
well as inactive contracts instead of just the active
ones it now returns. 

 The developer starts eclipse and makes sure that the
project is in his workspace and synched with the
cvs/source control repository. He finds the class he
wishes to modify in whatever package its in. When he
double clicks it the source for that service appears
in the editing area. He then proceeds to modify the
class slightly and save it locally. Once he saves it,
he runs the ant script that builds the war file. He
then ftps the war file to the development server and
waits for the app server to redeploy it (this can be
done as part of the ant script as well). He tests it
and sees  that it works. He then commits the changed
source to cvs and requests that a qa build take place
so that his changes may be tested (along with any
other changes that occured) by the dedicated testers.

 Either the developer or his lead then builds a qa war
in a separate build environment (maybe on his box,
maybe a dedicated server) and deploys it to the QA
server. The testers test it and certify that it works.
He makes a request to his lead to have it moved to
production. Once his change and any others are
scheduled they make the move to production.

--

Of course this example is a bit contrived, if you
designed your query/search right activity would just
be a flag you selected but it serves for illustration.
Also, it depends on how your build/testing/production
cycle is set up whether you have to go through all
these steps, but this is a common setup. There may
also be a few shortcuts for some of these areas on the
eclipse side as well.

 It does, I hope, illustrate how much easier server
side coding can be though. One thing it doesn't
illustrate is how much simpler a scripting langauge is
to make changes in as opposed to a systems language
like Java.


> We have a restricted ECMAScript version in the
> engine, with usually limited
> stuff implemented  in it, precisely because the GUI
> can be rather dumb
> (presentation, basic validation) while anything that
> requires
> intelligence or trust happens at the backend.

 Ahh, but you see the back end is usually not that
intelligent either. Not only that but the stuff the
standard business app does is usually pretty similar
across services.  I have been doing server side stuff
in Java for the last six or seven years 90% of the
time the business logic fits a very small set of
process. Usually something like 

  Test input for correctness
  Do something with a database/filesystem/etc.
  Possibly do some reformating and return a result.

  There are variations on this, and the other 10%
doesn't really fit into this mold and thats fine,
vanilla Polar wouldn't be a good fit for these areas.
But for the larger case of business applications you
can very easily write a set of APIs for each of the
major areas (in short order) and provide a fairly
simple and extremely fast way to script most of the
stanard type of services. 


> > Hopefully in the long term I can provide an
> integrated
> > IDE for the client applications as well.
> 
> As I said, *this* would be massively useful.

 Not a simple task an any case.

[snip ..]
 
> XWT will, on the client side. On the server side it
> really shouldn't
> matter much, and any environment that helps you get
> stuff done should
> suffice (see above).

 Most server environments don't help you get stuff
done. They give you an environment to publish your
services but they don't help you at all.

 Most of the server side stuff are variations on a
single theme and therefor lend themselves to
scripting. I am not talking about a mail server or
some type of game server, I am talking about the day
to day mundane business applications that are a large
percentage of the IT work that gets done. 


 [snip ...]
> 
> Don't by any means let my arguments discourage you
> if this particular
> project simply sparks your interest; I'm quite
> curious where Polar could
> go.


 No, no. As I said I plan to be my main customer so if
no one else ever uses it, it will still be a win for
me. In any case constructive criticism is never a bad
thing.

btw, I don't think this conversation is really
relevant to XWT anymore. If anyone wishes to continue
it may be best to take it off line. No need to tick
anyone off.

__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com