[erlang-questions] idea: service pack one
Alexander Lamb
alexander.lamb@REDACTED
Wed Nov 14 09:30:32 CET 2007
The big point here is:
- exchanging data to and from the client instead of generating a
client layout on the server. (although, you can sometimes do both at
the same time)
I totally agree the road to follow is RIA. Now, there are several ways
of doing this but the first thing to decide on is:
- what data format for the data exchange.
You suggest AMF which has the advantage of being usable "out of the
box" on the Flex side. It has the disadvantage if I am not mistaken to
be a proprietary format, not documented (Lazlo, RED5 and others
reverse engineered it).
Then, there is the protocole. In pur Web world, you are mostly all the
time fetching data (or HTML) from the server in HTTP. In trading apps,
you are pushing data to the client and there is no need for HTTP.
Other data formats could be JSON, Hessian, etc...
Transport protocole could be HTTP or AMQP (and there is even an Erlang
server for this).
Then, there is the mismatch (I think) between the way the client will
handle the data (and object graph most of the time) and the way the
server sees the data (records being acted upon through functions).
Any how, count me in to explore... we are currently begginners here
in Erlang but want to migrate part of our business to it (currently on
Cayenne / Tapestry / MySQL). In a previous life, I developped a
clinical system where the server pushed data to a client written in
Flash8.
Alex
--
Alexander Lamb
Founding Associate
RODANOTECH Sàrl
4 ch. de la Tour de Champel
1206 Geneva
Switzerland
Tel: 022 347 77 37
Fax: 022 347 77 38
http://www.rodanotech.ch
Le 13 nov. 07 à 22:48, Joe Armstrong a écrit :
> Re: flex 2 - has anybody got a *simple* example of a flex 2
> application that can communicate with
> erlang (through AMF) - I'm just reading up on flex 2/air it seems to
> be a perfect (client side) fit to Erlang
>
> /Joe
>
>
> On Nov 13, 2007 10:27 PM, Joe Armstrong <erlang@REDACTED> wrote:
>> Hi everybody,
>>
>> I got fired up with enthusiasm at the Erlang conference - it seems to
>> me that there are a lot of *simple* things we
>> can do that we should have done years ago. The reason was that even
>> though many aspects of the system
>> suck and can be *easily* improved we have learnt to live with the
>> system (warts and all).
>>
>> Now that the book is done my thoughts returned to the Erlang system.
>>
>> Erlang is becoming popular and now needs to address the problems that
>> our new users encounter.
>>
>> To do this I propose a project called "service pack one" (( its an
>> add-on that can be bolted on top of OTP))
>>
>> (( I don't want to change anything in OTP - just add a free-standing
>> set of scripts that modify the behavior
>> of the system ))
>>
>> Here's a few very simple things to do:
>>
>> (each of the things starting +++ is a little project --- now I'd like
>> volunteers for each project - most of these are pretty easy
>> to hack together a quick and dirty prototype - but needs a little
>> care
>> in getting all the details right)
>>
>>
>> 1 +++ fix nicer error messages (Done - Kenneth showed this)
>>
>> 2 +++ experiment with inheritance (Richard mentioned this) (( I
>> hacked
>> this together today, together with
>> some code that checks for missing calls in imported libraries))
>> - I can post a longer explanation if you like
>>
>> 3 +++ make Erlang start fast so that people stop winging about it
>> starting slowly. And fix a
>> *small* distribution - here's a minimal version.
>>
>> ((aside - who cares if Erlang starts slowly - it was designed to
>> start once and never stop - we have systems
>> that have run for 5 years - a two seconds start-up time amortized
>> over
>> 5 years is not *too* bad))
>>
>> (( If you want to make it fast redo the boot scripts - it's all in
>> the documentation ! ))
>>
>> (I tried this yesterday) it's really easy
>>
>>
>> 1) make a boot file (jboot.erl)
>>
>> {script, {"tiny","1.1"},
>> [{preLoaded,
>> [erlang,erl_prim_loader,prim_file,prim_inet,init,otp_ring0]},
>> {primLoad, [tiny]},
>> {kernel_load_completed},
>> {apply, {tiny, start, []}}]}.
>>
>> 2) write a minimal erlang program
>> tiny.erl
>> start() -> erlang:display'hello world'), erlang:halt().
>>
>> 3) compile the boot file
>> systools:script2boot("jboot").
>>
>> 4) run
>> erl -boot jboot
>>
>> This runs in 0.29 secs on my macbook
>>
>> (( for comparison erl -s init stop takes 1.6 seconds)
>>
>> 5) you also need the erl script:
>>
>> #!/bin/sh
>> ROOTDIR=`pwd`
>> BINDIR=$ROOTDIR
>> EMU=beam
>> PROGNAME=`echo $0 | sed 's/.*\///'`
>> export EMU
>> export ROOTDIR
>> export BINDIR
>> export PROGNAME
>> exec $BINDIR/erlexec ${1+"$@"}
>>
>> 6) copy erlexec and beam from the distribution to a local directory.
>> (these can be stripped to remove symbol table info)
>>
>> 7) the result is
>>
>> $ wc erl erlexec beam jboot.boot tiny.beam
>>
>> 10 20 172 erl
>> 58 277 22012 erlexec
>> 4247 35423 1097316 beam
>> 0 5 203 jboot.boot
>> 5 20 708 tiny.beam
>> 4320 35745 1120411 total
>>
>> 1.1 MB and 6 files - not *too* bad
>>
>> 8) for fun I packed stdlib/kernel/compiler in an archive using
>> boot_tools:mk_lib() which packs everything a single 1.14 meg
>> archive
>> (boot_tools is in $DIST/otp_src_R11B-4/erts/boot/src
>>
>> This means we can pack the compiler and base otp system into half a
>> dozen files
>> and under 2.5 Meg
>>
>> (( this was my old sae sysytem that never really made it to the
>> main release))
>>
>> 4 +++ compile the @spec definitions in comments into code that
>> *dynamically* checks types
>> who cares if it's slow and can't be checked statically - the
>> dynamic check is very useful
>> while developing
>>
>> 5 +++ bundle ejabberd (or yaws) in a standard configuration that
>> ships
>> with Erlang.
>> I talked to Mickael R. about this - if we shipped ejabberd
>> with every Erlang
>> we could easily get tens of thousands of ejabberd servers up
>> and running in
>> the twinkling of an eye.
>>
>> 6 ++++ fix BIFs for regexp, searching binaries etc - so people stop
>> winging
>>
>> 7 ++++ fix c(Mod) and erlc so that they throw *everything* at them ie
>> dynamic type checking,
>> xref, cover, dialyzer *without* you having to do
>> anything fancy
>> the defaults for compilation should be to throw all
>> checks possible into the compile
>> cycle
>>
>> 8 ++++ make an *erlang* packing mechanism (put the entire application
>> in a .dets file - and NOT
>> .tar.gz or zip file - then define a bundle structure (look at the MAC
>> for inspiration) add application icons
>> and a desktop interface.
>>
>> 9 ++++ interface to flash using flex 2. Solve the GUI problem once
>> and
>> for all as follows
>>
>> repeat after me: client = flash in the browser, server = erlang.
>> Intermediate protocol = flash AMF
>>
>>
>> There are probably more things I could add - feel free to add you pet
>> annoyance that can be easily
>> fixed and we'll put it into service pack one.
>>
>>
>>
>> Cheers
>>
>> /Joe Armstrong
>>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions
>
More information about the erlang-questions
mailing list