| Author |
Message |
|
| Guest |
 Posted: Sat Feb 09, 2008 5:21 am |
 |
|
|
Guest
|
I've been looking at some of the other web frame works out there and my
own code looking for ideas to improve matters in erlyweb. One thing that
I've noticed is that I'm repeating things in the view that I've written
in the controller but only in a slightly different way. I've noticed
that many of the web developement frame works that don't use MVC use a
model and a canvas analogy to save on this repetition.
An example of what I'm thinking: create a page with a link and a form
with one text field and a submit button.
-module(simple_controller).
new(_A) ->
%% include a call back function with the link
Link = html_link:new("hello", fun() ->
"hello there!"
end),
TextField = html_input:text_field(),
Submit = html_input:submit(),
%% include a call back function with the form
Form = html_form:new(fun(Fields) ->
simple:process_new(Fields)
end),
Form1 = html_form:add(Form, TextField),
Form2 = html_form:add(Form1, Submit),
Base = html_div:new(),
Base1 = html_div:add(Base, Link),
Base2 = html_div:add(Base, Form),
Base2.
render(Layout) ->
html:render(Layout).
Rough internal representation,
{div, ..., [
{link, LinkId, "hello", CallBackFun},
{form, FormId, CallBack, [
{input, text_field, FieldId, Value},
{input, submit, SubmitId, undefined}
]
}
]
}
Output
<div>
<a href="http://server/simple/_12345_>hello</a>
<form action="http://server/simple/_12346_">
<input type="text"/>
<input type="submit"/>
</form>
</div>
Now there's bound to be errors in the above, but I the basic idea should
be clear. The html is generated much like a GUI, say, wxwidgets or Qt.
call back functions are added to direct process flow, Ids are
automatically generated to direct processing to the correct callback.
Rest style URLs are still processed as is, ie http://server/simple/new
will call the above new/1 function.
There's still abit unclear about this. For example, what's the best way
to alter/add attributes to the html without it becoming to verbose.
This started as scribles in a note book as I waited for a meeting to
begin a couple of days ago and is being posted "as is" after I saw
yariv's posts about arc this morning.
Jeff.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "erlyweb" group.
To post to this group, send email to erlyweb@googlegroups.com
To unsubscribe from this group, send email to erlyweb-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/erlyweb?hl=en
-~----------~----~----~----~------~----~------~--~---
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Sat Feb 09, 2008 10:32 am |
|
|
|
Guest
|
I have been thinking too about how in some cases (as in the Arc
challenge), it looks like creating the html in the controller using
function calls or objects (like ehtml) and skipping the view could
make the code shorter. My current impression -- and I could be wrong
-- is that Arc style programming works better when most of the content
is dynamic and that ErlyWeb style works better when you have large
amounts of static html in which small amounts of dynamic data is
embedded.
Btw, you can bypass views today by returning {response, [...]}, so
nothing is preventing you from doing Arc style programming in ErlyWeb.
You just have to write some library functions for generating html
entities and maybe add support for continuations in ErlyWeb (this
isn't too hard).
Yariv
On Feb 8, 2008 9:23 PM, jm <jeffm@ghostgun.com> wrote:
>
> I've been looking at some of the other web frame works out there and my
> own code looking for ideas to improve matters in erlyweb. One thing that
> I've noticed is that I'm repeating things in the view that I've written
> in the controller but only in a slightly different way. I've noticed
> that many of the web developement frame works that don't use MVC use a
> model and a canvas analogy to save on this repetition.
>
> An example of what I'm thinking: create a page with a link and a form
> with one text field and a submit button.
>
> -module(simple_controller).
>
> new(_A) ->
> %% include a call back function with the link
> Link = html_link:new("hello", fun() ->
> "hello there!"
> end),
> TextField = html_input:text_field(),
> Submit = html_input:submit(),
>
> %% include a call back function with the form
> Form = html_form:new(fun(Fields) ->
> simple:process_new(Fields)
> end),
> Form1 = html_form:add(Form, TextField),
> Form2 = html_form:add(Form1, Submit),
>
> Base = html_div:new(),
> Base1 = html_div:add(Base, Link),
> Base2 = html_div:add(Base, Form),
> Base2.
>
>
> render(Layout) ->
> html:render(Layout).
>
>
> Rough internal representation,
>
> {div, ..., [
> {link, LinkId, "hello", CallBackFun},
> {form, FormId, CallBack, [
> {input, text_field, FieldId, Value},
> {input, submit, SubmitId, undefined}
> ]
> }
> ]
> }
>
>
> Output
> <div>
> <a href="http://server/simple/_12345_>hello</a>
> <form action="http://server/simple/_12346_">
> <input type="text"/>
> <input type="submit"/>
> </form>
> </div>
>
> Now there's bound to be errors in the above, but I the basic idea should
> be clear. The html is generated much like a GUI, say, wxwidgets or Qt.
> call back functions are added to direct process flow, Ids are
> automatically generated to direct processing to the correct callback.
> Rest style URLs are still processed as is, ie http://server/simple/new
> will call the above new/1 function.
>
> There's still abit unclear about this. For example, what's the best way
> to alter/add attributes to the html without it becoming to verbose.
>
> This started as scribles in a note book as I waited for a meeting to
> begin a couple of days ago and is being posted "as is" after I saw
> yariv's posts about arc this morning.
>
> Jeff.
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "erlyweb" group.
To post to this group, send email to erlyweb@googlegroups.com
To unsubscribe from this group, send email to erlyweb-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/erlyweb?hl=en
-~----------~----~----~----~------~----~------~--~---
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Sat Feb 09, 2008 10:33 am |
|
|
|
Guest
|
Btw, also check out Yaws's ehtml. It's quite similar to what you described.
On Feb 9, 2008 2:31 AM, Yariv Sadan <yarivsadan@gmail.com> wrote:
> I have been thinking too about how in some cases (as in the Arc
> challenge), it looks like creating the html in the controller using
> function calls or objects (like ehtml) and skipping the view could
> make the code shorter. My current impression -- and I could be wrong
> -- is that Arc style programming works better when most of the content
> is dynamic and that ErlyWeb style works better when you have large
> amounts of static html in which small amounts of dynamic data is
> embedded.
>
> Btw, you can bypass views today by returning {response, [...]}, so
> nothing is preventing you from doing Arc style programming in ErlyWeb.
> You just have to write some library functions for generating html
> entities and maybe add support for continuations in ErlyWeb (this
> isn't too hard).
>
> Yariv
>
>
> On Feb 8, 2008 9:23 PM, jm <jeffm@ghostgun.com> wrote:
> >
> > I've been looking at some of the other web frame works out there and my
> > own code looking for ideas to improve matters in erlyweb. One thing that
> > I've noticed is that I'm repeating things in the view that I've written
> > in the controller but only in a slightly different way. I've noticed
> > that many of the web developement frame works that don't use MVC use a
> > model and a canvas analogy to save on this repetition.
> >
> > An example of what I'm thinking: create a page with a link and a form
> > with one text field and a submit button.
> >
> > -module(simple_controller).
> >
> > new(_A) ->
> > %% include a call back function with the link
> > Link = html_link:new("hello", fun() ->
> > "hello there!"
> > end),
> > TextField = html_input:text_field(),
> > Submit = html_input:submit(),
> >
> > %% include a call back function with the form
> > Form = html_form:new(fun(Fields) ->
> > simple:process_new(Fields)
> > end),
> > Form1 = html_form:add(Form, TextField),
> > Form2 = html_form:add(Form1, Submit),
> >
> > Base = html_div:new(),
> > Base1 = html_div:add(Base, Link),
> > Base2 = html_div:add(Base, Form),
> > Base2.
> >
> >
> > render(Layout) ->
> > html:render(Layout).
> >
> >
> > Rough internal representation,
> >
> > {div, ..., [
> > {link, LinkId, "hello", CallBackFun},
> > {form, FormId, CallBack, [
> > {input, text_field, FieldId, Value},
> > {input, submit, SubmitId, undefined}
> > ]
> > }
> > ]
> > }
> >
> >
> > Output
> > <div>
> > <a href="http://server/simple/_12345_>hello</a>
> > <form action="http://server/simple/_12346_">
> > <input type="text"/>
> > <input type="submit"/>
> > </form>
> > </div>
> >
> > Now there's bound to be errors in the above, but I the basic idea should
> > be clear. The html is generated much like a GUI, say, wxwidgets or Qt.
> > call back functions are added to direct process flow, Ids are
> > automatically generated to direct processing to the correct callback.
> > Rest style URLs are still processed as is, ie http://server/simple/new
> > will call the above new/1 function.
> >
> > There's still abit unclear about this. For example, what's the best way
> > to alter/add attributes to the html without it becoming to verbose.
> >
> > This started as scribles in a note book as I waited for a meeting to
> > begin a couple of days ago and is being posted "as is" after I saw
> > yariv's posts about arc this morning.
> >
> > Jeff.
> >
> >
> > > >
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "erlyweb" group.
To post to this group, send email to erlyweb@googlegroups.com
To unsubscribe from this group, send email to erlyweb-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/erlyweb?hl=en
-~----------~----~----~----~------~----~------~--~---
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Mon Feb 11, 2008 6:14 am |
|
|
|
Guest
|
Yariv Sadan wrote:
> I have been thinking too about how in some cases (as in the Arc
> challenge), it looks like creating the html in the controller using
> function calls or objects (like ehtml) and skipping the view could
> make the code shorter. My current impression -- and I could be wrong
> -- is that Arc style programming works better when most of the content
> is dynamic and that ErlyWeb style works better when you have large
> amounts of static html in which small amounts of dynamic data is
> embedded.
>
> Btw, you can bypass views today by returning {response, [...]}, so
> nothing is preventing you from doing Arc style programming in ErlyWeb.
> You just have to write some library functions for generating html
> entities and maybe add support for continuations in ErlyWeb (this
> isn't too hard).
>
I was think of "unrolling continuations". Unrolling similarly to loop
unrolling in language compilers. One of the problems with continuations
is the amount of memory consumed. I watched a talk off google video by
one of the developers of seaside, sorry can't remember which talk, where
he was asked how much memory was consumed by the use of continuations.
He stated about 2MB per session. He was likely making a "guessimate"
based on he's experience and not base on actual measurements but even so
that's alot. When you consider that for most sites most of the time the
use of continuations is to allow the extra functionality it provides is
unwarranted. Being mostly queries of static data versus editing,
multipart forms and the dreaded shopping cart example. In fact the use
of continuations and the associated session can be annoying. Consider
the seaside tutorial located at
http://www.swa.hpi.uni-potsdam.de/seaside/tutorial. I aim to read about
a page a day, but the session information times out and I have to go
back to the first page before finding my place. Very frustrating. It
would be much better to have this functionality turned off by default
and only turn it on as needed.
Anyway, what I was thinking it might be possible to "unrolling
continuations" in loose terms. Would it be possible to do this is such a
way as to,
1) reduce memory usage
2) be able to turn it on only for a section of code
3) serial to a database such as mnesia, so that,
4) unlike continuations be distributed for the purposes of redundancy
and load balancing.
Can anyone point be to some good references on continuation so that I
can actually get a deep understanding of continuations, etc?
trying to run out the door,
Jeff.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "erlyweb" group.
To post to this group, send email to erlyweb@googlegroups.com
To unsubscribe from this group, send email to erlyweb-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/erlyweb?hl=en
-~----------~----~----~----~------~----~------~--~---
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Tue Feb 12, 2008 4:19 am |
|
|
|
Guest
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I would suggest you read:
http://www.ccs.neu.edu/home/dorai/t-y-scheme/t-y-scheme-Z-H-15.html
http://www.bookshelf.jp/texi/onlisp/onlisp_21.html
- -Kenny
On Feb 11, 2008, at 1:16 AM, jm wrote:
>
> Yariv Sadan wrote:
>> I have been thinking too about how in some cases (as in the Arc
>> challenge), it looks like creating the html in the controller using
>> function calls or objects (like ehtml) and skipping the view could
>> make the code shorter. My current impression -- and I could be wrong
>> -- is that Arc style programming works better when most of the
>> content
>> is dynamic and that ErlyWeb style works better when you have large
>> amounts of static html in which small amounts of dynamic data is
>> embedded.
>>
>> Btw, you can bypass views today by returning {response, [...]}, so
>> nothing is preventing you from doing Arc style programming in
>> ErlyWeb.
>> You just have to write some library functions for generating html
>> entities and maybe add support for continuations in ErlyWeb (this
>> isn't too hard).
>>
>
> I was think of "unrolling continuations". Unrolling similarly to loop
> unrolling in language compilers. One of the problems with
> continuations
> is the amount of memory consumed. I watched a talk off google video by
> one of the developers of seaside, sorry can't remember which talk,
> where
> he was asked how much memory was consumed by the use of continuations.
> He stated about 2MB per session. He was likely making a "guessimate"
> based on he's experience and not base on actual measurements but
> even so
> that's alot. When you consider that for most sites most of the time
> the
> use of continuations is to allow the extra functionality it
> provides is
> unwarranted. Being mostly queries of static data versus editing,
> multipart forms and the dreaded shopping cart example. In fact the use
> of continuations and the associated session can be annoying. Consider
> the seaside tutorial located at
> http://www.swa.hpi.uni-potsdam.de/seaside/tutorial. I aim to read
> about
> a page a day, but the session information times out and I have to go
> back to the first page before finding my place. Very frustrating. It
> would be much better to have this functionality turned off by default
> and only turn it on as needed.
>
> Anyway, what I was thinking it might be possible to "unrolling
> continuations" in loose terms. Would it be possible to do this is
> such a
> way as to,
>
> 1) reduce memory usage
> 2) be able to turn it on only for a section of code
> 3) serial to a database such as mnesia, so that,
> 4) unlike continuations be distributed for the purposes of redundancy
> and load balancing.
>
> Can anyone point be to some good references on continuation so that I
> can actually get a deep understanding of continuations, etc?
>
> trying to run out the door,
> Jeff.
>
> >
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
iEYEARECAAYFAkexHgoACgkQD1o2p99G7hZfQgCgwg/87YdaqPJP/W5J574Gl/uH
/hEAnAtRULK29EgOyW2QAPJi8smlCM8z
=5iut
-----END PGP SIGNATURE-----
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "erlyweb" group.
To post to this group, send email to erlyweb@googlegroups.com
To unsubscribe from this group, send email to erlyweb-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/erlyweb?hl=en
-~----------~----~----~----~------~----~------~--~---
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Wed Feb 13, 2008 6:36 am |
|
|
|
Guest
|
My impression (and I could be very wrong because I haven't used a
continuations-based framework) is that continuations can be useful to
streamline the code for some multi-page interactions, but for general
web development purposes they cause too many problems: non meaningful
URLs, sticky load balancing, no back button support, no crash
recovery, and apparently also high memory requirements (I'm not sure
why, but I'll take your word for it.)
Also, I'm not sure that continuations create such a dramatic decrease
in code size. Consider these two similar examples, one that uses
continuations and one that doesn't (I'm using the terms continuation
and closure interchangeably here):
index(A) ->
form([input("name"), input("age"), submit()],
fun(A1) ->
[Name, Age] = [get_param(A1, "name"), get_param(A1, "age")],
save(Name, Age)
end).
index(A) ->
case method(A) of
'GET' ->
form([input("name"), input("age"), submit()]);
'POST' ->
[Name, Age] = [get_param(A, "name"), get_param(A, "age")],
save(Name, Age)
end.
Is the first version really that much better?
By the way, you can write code that looks like it uses continuations
but without any framework support:
index(A) ->
get_inputs(A, ["name", "age"],
fun([Name, Age]) -> save(Name, Age) end).
with this utility function:
get_inputs(A, Inputs, Fun) ->
case method(A) of
'GET' ->
form([input(Input) || Input <- Inputs] ++ submit());
'POST' ->
Fun([get_param(A, Input) || Input <- Inputs])
end.
I'll appreciate any enlightenment in case I'm missing something big here.
Yariv
>
> I was think of "unrolling continuations". Unrolling similarly to loop
> unrolling in language compilers. One of the problems with continuations
> is the amount of memory consumed. I watched a talk off google video by
> one of the developers of seaside, sorry can't remember which talk, where
> he was asked how much memory was consumed by the use of continuations.
> He stated about 2MB per session. He was likely making a "guessimate"
> based on he's experience and not base on actual measurements but even so
> that's alot. When you consider that for most sites most of the time the
> use of continuations is to allow the extra functionality it provides is
> unwarranted. Being mostly queries of static data versus editing,
> multipart forms and the dreaded shopping cart example. In fact the use
> of continuations and the associated session can be annoying. Consider
> the seaside tutorial located at
> http://www.swa.hpi.uni-potsdam.de/seaside/tutorial. I aim to read about
> a page a day, but the session information times out and I have to go
> back to the first page before finding my place. Very frustrating. It
> would be much better to have this functionality turned off by default
> and only turn it on as needed.
>
> Anyway, what I was thinking it might be possible to "unrolling
> continuations" in loose terms. Would it be possible to do this is such a
> way as to,
>
> 1) reduce memory usage
> 2) be able to turn it on only for a section of code
> 3) serial to a database such as mnesia, so that,
> 4) unlike continuations be distributed for the purposes of redundancy
> and load balancing.
>
> Can anyone point be to some good references on continuation so that I
> can actually get a deep understanding of continuations, etc?
>
> trying to run out the door,
>
> Jeff.
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "erlyweb" group.
To post to this group, send email to erlyweb@googlegroups.com
To unsubscribe from this group, send email to erlyweb-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/erlyweb?hl=en
-~----------~----~----~----~------~----~------~--~---
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Wed Feb 13, 2008 9:33 am |
|
|
|
Guest
|
Dang, I actually realized I just overlooked something big: my examples
didn't use real closures -- just anonymous functions. With framework
support, those functions could be used as closures and their
environment data could be accessible in subsequent actions without the
controller's using the session store explicitly. I should have thought
a bit harder before voicing my skepticism  (However, I believe some
of the disadvantages I listed still hold true.)
Yariv
On Feb 12, 2008 10:35 PM, Yariv Sadan <yarivsadan@gmail.com> wrote:
> My impression (and I could be very wrong because I haven't used a
> continuations-based framework) is that continuations can be useful to
> streamline the code for some multi-page interactions, but for general
> web development purposes they cause too many problems: non meaningful
> URLs, sticky load balancing, no back button support, no crash
> recovery, and apparently also high memory requirements (I'm not sure
> why, but I'll take your word for it.)
>
> Also, I'm not sure that continuations create such a dramatic decrease
> in code size. Consider these two similar examples, one that uses
> continuations and one that doesn't (I'm using the terms continuation
> and closure interchangeably here):
>
> index(A) ->
> form([input("name"), input("age"), submit()],
> fun(A1) ->
> [Name, Age] = [get_param(A1, "name"), get_param(A1, "age")],
> save(Name, Age)
> end).
>
> index(A) ->
> case method(A) of
> 'GET' ->
> form([input("name"), input("age"), submit()]);
> 'POST' ->
> [Name, Age] = [get_param(A, "name"), get_param(A, "age")],
> save(Name, Age)
> end.
>
> Is the first version really that much better?
>
> By the way, you can write code that looks like it uses continuations
> but without any framework support:
>
> index(A) ->
> get_inputs(A, ["name", "age"],
> fun([Name, Age]) -> save(Name, Age) end).
>
> with this utility function:
>
> get_inputs(A, Inputs, Fun) ->
> case method(A) of
> 'GET' ->
> form([input(Input) || Input <- Inputs] ++ submit());
> 'POST' ->
> Fun([get_param(A, Input) || Input <- Inputs])
> end.
>
> I'll appreciate any enlightenment in case I'm missing something big here.
>
> Yariv
>
>
> >
> > I was think of "unrolling continuations". Unrolling similarly to loop
> > unrolling in language compilers. One of the problems with continuations
> > is the amount of memory consumed. I watched a talk off google video by
> > one of the developers of seaside, sorry can't remember which talk, where
> > he was asked how much memory was consumed by the use of continuations.
> > He stated about 2MB per session. He was likely making a "guessimate"
> > based on he's experience and not base on actual measurements but even so
> > that's alot. When you consider that for most sites most of the time the
> > use of continuations is to allow the extra functionality it provides is
> > unwarranted. Being mostly queries of static data versus editing,
> > multipart forms and the dreaded shopping cart example. In fact the use
> > of continuations and the associated session can be annoying. Consider
> > the seaside tutorial located at
> > http://www.swa.hpi.uni-potsdam.de/seaside/tutorial. I aim to read about
> > a page a day, but the session information times out and I have to go
> > back to the first page before finding my place. Very frustrating. It
> > would be much better to have this functionality turned off by default
> > and only turn it on as needed.
> >
> > Anyway, what I was thinking it might be possible to "unrolling
> > continuations" in loose terms. Would it be possible to do this is such a
> > way as to,
> >
> > 1) reduce memory usage
> > 2) be able to turn it on only for a section of code
> > 3) serial to a database such as mnesia, so that,
> > 4) unlike continuations be distributed for the purposes of redundancy
> > and load balancing.
> >
> > Can anyone point be to some good references on continuation so that I
> > can actually get a deep understanding of continuations, etc?
> >
> > trying to run out the door,
> >
> > Jeff.
> >
> > > >
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "erlyweb" group.
To post to this group, send email to erlyweb@googlegroups.com
To unsubscribe from this group, send email to erlyweb-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/erlyweb?hl=en
-~----------~----~----~----~------~----~------~--~---
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Wed Feb 13, 2008 10:01 am |
|
|
|
Guest
|
Yariv,
I suggest you have a look at seaside. Continuations not only make the
code development easy, but you can suddenly start to develop "true"
components and they are straightforwardly embeddable - the complexity
of mixing and matching components becomes additive rather the
geometric if that makes sense.
I can't explain the gist of my argument - its one of those matrix
things - when it sinks in you go "Wow!".
Why am I still programming in erlang? I really like the scalability
and a lot of my applications need lots of concurrent processes.
I have been told any system that supports first class function objects
with lexical closure is able to support continuation passing style - I
think it would even be easier with erlang considering you don't have
to worry about variable mutations and the like.
hafeez
On Feb 13, 8:32 pm, "Yariv Sadan" <yarivsa...@gmail.com> wrote:
> Dang, I actually realized I just overlooked something big: my examples
> didn't use real closures -- just anonymous functions. With framework
> support, those functions could be used as closures and their
> environment data could be accessible in subsequent actions without the
> controller's using the session store explicitly. I should have thought
> a bit harder before voicing my skepticism (However, I believe some
> of the disadvantages I listed still hold true.)
>
> Yariv
>
> On Feb 12, 2008 10:35 PM, Yariv Sadan <yarivsa...@gmail.com> wrote:
>
> > My impression (and I could be very wrong because I haven't used a
> > continuations-based framework) is that continuations can be useful to
> > streamline the code for some multi-page interactions, but for general
> > web development purposes they cause too many problems: non meaningful
> > URLs, sticky load balancing, no back button support, no crash
> > recovery, and apparently also high memory requirements (I'm not sure
> > why, but I'll take your word for it.)
>
> > Also, I'm not sure that continuations create such a dramatic decrease
> > in code size. Consider these two similar examples, one that uses
> > continuations and one that doesn't (I'm using the terms continuation
> > and closure interchangeably here):
>
> > index(A) ->
> > form([input("name"), input("age"), submit()],
> > fun(A1) ->
> > [Name, Age] = [get_param(A1, "name"), get_param(A1, "age")],
> > save(Name, Age)
> > end).
>
> > index(A) ->
> > case method(A) of
> > 'GET' ->
> > form([input("name"), input("age"), submit()]);
> > 'POST' ->
> > [Name, Age] = [get_param(A, "name"), get_param(A, "age")],
> > save(Name, Age)
> > end.
>
> > Is the first version really that much better?
>
> > By the way, you can write code that looks like it uses continuations
> > but without any framework support:
>
> > index(A) ->
> > get_inputs(A, ["name", "age"],
> > fun([Name, Age]) -> save(Name, Age) end).
>
> > with this utility function:
>
> > get_inputs(A, Inputs, Fun) ->
> > case method(A) of
> > 'GET' ->
> > form([input(Input) || Input <- Inputs] ++ submit());
> > 'POST' ->
> > Fun([get_param(A, Input) || Input <- Inputs])
> > end.
>
> > I'll appreciate any enlightenment in case I'm missing something big here.
>
> > Yariv
>
> > > I was think of "unrolling continuations". Unrolling similarly to loop
> > > unrolling in language compilers. One of the problems with continuations
> > > is the amount of memory consumed. I watched a talk off google video by
> > > one of the developers of seaside, sorry can't remember which talk, where
> > > he was asked how much memory was consumed by the use of continuations.
> > > He stated about 2MB per session. He was likely making a "guessimate"
> > > based on he's experience and not base on actual measurements but even so
> > > that's alot. When you consider that for most sites most of the time the
> > > use of continuations is to allow the extra functionality it provides is
> > > unwarranted. Being mostly queries of static data versus editing,
> > > multipart forms and the dreaded shopping cart example. In fact the use
> > > of continuations and the associated session can be annoying. Consider
> > > the seaside tutorial located at
> > >http://www.swa.hpi.uni-potsdam.de/seaside/tutorial. I aim to read about
> > > a page a day, but the session information times out and I have to go
> > > back to the first page before finding my place. Very frustrating. It
> > > would be much better to have this functionality turned off by default
> > > and only turn it on as needed.
>
> > > Anyway, what I was thinking it might be possible to "unrolling
> > > continuations" in loose terms. Would it be possible to do this is such a
> > > way as to,
>
> > > 1) reduce memory usage
> > > 2) be able to turn it on only for a section of code
> > > 3) serial to a database such as mnesia, so that,
> > > 4) unlike continuations be distributed for the purposes of redundancy
> > > and load balancing.
>
> > > Can anyone point be to some good references on continuation so that I
> > > can actually get a deep understanding of continuations, etc?
>
> > > trying to run out the door,
>
> > > Jeff.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "erlyweb" group.
To post to this group, send email to erlyweb@googlegroups.com
To unsubscribe from this group, send email to erlyweb-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/erlyweb?hl=en
-~----------~----~----~----~------~----~------~--~---
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Thu Feb 14, 2008 2:13 am |
|
|
|
Guest
|
macrocreation wrote:
> Yariv,
>
> I suggest you have a look at seaside. Continuations not only make the
> code development easy, but you can suddenly start to develop "true"
> components and they are straightforwardly embeddable - the complexity
> of mixing and matching components becomes additive rather the
> geometric if that makes sense.
This is the argument I've heard in favor of it as well.
The bit that made the most sense to me why you'd want to do this is not
the reduction in code size (I don't think there is), but the ability to
think and code dirictly in a process flow manner instead of a finite
state machine's transitions. FSMs cause problems as they grow larger and
more complex as it gets harder to fit it all in one's head at the sametime.
Consider this bad ASCII art, adopted from "Inverting back the inversion
of control or, Continuations versus page-centric programming"
get post post
----->[get num1]----->[get num2]---->[display num1 + num2]
using the current erlyweb we'd have something like, ignoring error cases,
-module(traditional)
add(A) ->
case Method of
'GET' ->
generate_num1_form(A);
'POST' ->
F = get_fields_from_form(A),
%% uses client to store num1 as hidden field in 2nd form
case proplists:lookup(num1, F) of
none -> {ewr, traditional, add};
N1 -> case proplists:lookup(num2) of
none -> generate_num2_form(A, N1);
N2 -> generate_sum_page(A, N1, N2)
end
end
end.
What would this look like in an Erlang/Erlyweb with continuation? I'll
leave this for someone else as this what I'm trying to work out. In
psuedo code
add(A) ->
N1 = get_num1(A),
N2 = get_num2(A),
generate_sum_page(A, N1, N2).
get_num1(A) ->
generate_num1_form(A),
break/resume
F = get_fields_from_form(A),
proplists:lookup(num1, F).
get_num2(A) ->
generate_num2_form(A),
break/resume
F = get_fields_from_form(A),
proplists:lookup(num2, F).
which is really just the previous code turned inside out. The bit I'm
stumbling on at the moment is error control and branching of flow
(case/if) and how it fits into this.
Regardless, I can't understand why continuations would use so much
memory. The only things I can think of are
1) The estimate I heard was wrong.
2) The estimate I heard was for large applications
3) This is due to saving the full stack for each call (post/get) and
then keeping the old stacks around for a long time.
I keep seeing not stacks but changes in state forming a tree of changes.
ie, erlyweb taking snapshots of the values of functions at the
break/resume points but not the entire stack and these for the node of a
state tree in time.
Lasty, thanks to k.parnell@gmail.com for recommending a couple of papers
I'm only half through the first one as I'm not formilar with scheme. In
searching I also found this archived message which seems to indicate
some relevent papers,
http://www.cs.brown.edu/pipermail/plt-scheme/2007-April/017628.html
Jeff.
> I can't explain the gist of my argument - its one of those matrix
> things - when it sinks in you go "Wow!".
>
> Why am I still programming in erlang? I really like the scalability
> and a lot of my applications need lots of concurrent processes.
>
> I have been told any system that supports first class function objects
> with lexical closure is able to support continuation passing style - I
> think it would even be easier with erlang considering you don't have
> to worry about variable mutations and the like.
>
> hafeez
>
>
> On Feb 13, 8:32 pm, "Yariv Sadan" <yarivsa...@gmail.com> wrote:
>> Dang, I actually realized I just overlooked something big: my examples
>> didn't use real closures -- just anonymous functions. With framework
>> support, those functions could be used as closures and their
>> environment data could be accessible in subsequent actions without the
>> controller's using the session store explicitly. I should have thought
>> a bit harder before voicing my skepticism (However, I believe some
>> of the disadvantages I listed still hold true.)
>>
>> Yariv
>>
>> On Feb 12, 2008 10:35 PM, Yariv Sadan <yarivsa...@gmail.com> wrote:
>>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "erlyweb" group.
To post to this group, send email to erlyweb@googlegroups.com
To unsubscribe from this group, send email to erlyweb-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/erlyweb?hl=en
-~----------~----~----~----~------~----~------~--~---
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Sat Feb 16, 2008 4:47 am |
|
|
|
Guest
|
This paper:
http://siscweb.sourceforge.net/docs/queinnec-inverting.pdf
helped me have the "aha!" moment using continuations and the web. If
you're comfortable reading Scheme, siscweb has a decent implementation
of continuation-based web programming, too. It might be good source
for ideas.
--Kevin
On Feb 13, 2008, at 9:12 PM, jm wrote:
>
> macrocreation wrote:
>> Yariv,
>>
>> I suggest you have a look at seaside. Continuations not only make the
>> code development easy, but you can suddenly start to develop "true"
>> components and they are straightforwardly embeddable - the complexity
>> of mixing and matching components becomes additive rather the
>> geometric if that makes sense.
>
> This is the argument I've heard in favor of it as well.
>
> The bit that made the most sense to me why you'd want to do this is
> not
> the reduction in code size (I don't think there is), but the ability
> to
> think and code dirictly in a process flow manner instead of a finite
> state machine's transitions. FSMs cause problems as they grow larger
> and
> more complex as it gets harder to fit it all in one's head at the
> sametime.
>
> Consider this bad ASCII art, adopted from "Inverting back the
> inversion
> of control or, Continuations versus page-centric programming"
>
> get post post
> ----->[get num1]----->[get num2]---->[display num1 + num2]
>
>
> using the current erlyweb we'd have something like, ignoring error
> cases,
>
> -module(traditional)
>
>
> add(A) ->
> case Method of
> 'GET' ->
> generate_num1_form(A);
> 'POST' ->
> F = get_fields_from_form(A),
> %% uses client to store num1 as hidden field in 2nd form
> case proplists:lookup(num1, F) of
> none -> {ewr, traditional, add};
> N1 -> case proplists:lookup(num2) of
> none -> generate_num2_form(A, N1);
> N2 -> generate_sum_page(A, N1, N2)
> end
> end
> end.
>
>
> What would this look like in an Erlang/Erlyweb with continuation? I'll
> leave this for someone else as this what I'm trying to work out. In
> psuedo code
>
> add(A) ->
> N1 = get_num1(A),
> N2 = get_num2(A),
> generate_sum_page(A, N1, N2).
>
>
> get_num1(A) ->
> generate_num1_form(A),
> break/resume
> F = get_fields_from_form(A),
> proplists:lookup(num1, F).
>
>
> get_num2(A) ->
> generate_num2_form(A),
> break/resume
> F = get_fields_from_form(A),
> proplists:lookup(num2, F).
>
>
> which is really just the previous code turned inside out. The bit I'm
> stumbling on at the moment is error control and branching of flow
> (case/if) and how it fits into this.
>
> Regardless, I can't understand why continuations would use so much
> memory. The only things I can think of are
> 1) The estimate I heard was wrong.
> 2) The estimate I heard was for large applications
> 3) This is due to saving the full stack for each call (post/get) and
> then keeping the old stacks around for a long time.
>
> I keep seeing not stacks but changes in state forming a tree of
> changes.
> ie, erlyweb taking snapshots of the values of functions at the
> break/resume points but not the entire stack and these for the node
> of a
> state tree in time.
>
> Lasty, thanks to k.parnell@gmail.com for recommending a couple of
> papers
> I'm only half through the first one as I'm not formilar with scheme.
> In
> searching I also found this archived message which seems to indicate
> some relevent papers,
>
> http://www.cs.brown.edu/pipermail/plt-scheme/2007-April/017628.html
>
> Jeff.
>
>> I can't explain the gist of my argument - its one of those matrix
>> things - when it sinks in you go "Wow!".
>>
>> Why am I still programming in erlang? I really like the scalability
>> and a lot of my applications need lots of concurrent processes.
>>
>> I have been told any system that supports first class function
>> objects
>> with lexical closure is able to support continuation passing style
>> - I
>> think it would even be easier with erlang considering you don't have
>> to worry about variable mutations and the like.
>>
>> hafeez
>>
>>
>> On Feb 13, 8:32 pm, "Yariv Sadan" <yarivsa...@gmail.com> wrote:
>>> Dang, I actually realized I just overlooked something big: my
>>> examples
>>> didn't use real closures -- just anonymous functions. With framework
>>> support, those functions could be used as closures and their
>>> environment data could be accessible in subsequent actions without
>>> the
>>> controller's using the session store explicitly. I should have
>>> thought
>>> a bit harder before voicing my skepticism (However, I believe
>>> some
>>> of the disadvantages I listed still hold true.)
>>>
>>> Yariv
>>>
>>> On Feb 12, 2008 10:35 PM, Yariv Sadan <yarivsa...@gmail.com> wrote:
>>>
>
>
> >
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "erlyweb" group.
To post to this group, send email to erlyweb@googlegroups.com
To unsubscribe from this group, send email to erlyweb-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/erlyweb?hl=en
-~----------~----~----~----~------~----~------~--~---
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Mon Feb 18, 2008 5:16 am |
|
|
|
Guest
|
Thanks for the link! I hacked a rudimentary continuations plugin for
ErlyWeb. I wrote about it at
http://yarivsblog.com/articles/2008/02/17/seaside-style-programming-in-erlyweb/.
I'd love to get people's feedback on it.
Yariv
On Feb 15, 2008 8:47 PM, Kevin A. Smith <kevin@hypotheticalabs.com> wrote:
>
> This paper:
>
> http://siscweb.sourceforge.net/docs/queinnec-inverting.pdf
>
> helped me have the "aha!" moment using continuations and the web. If
> you're comfortable reading Scheme, siscweb has a decent implementation
> of continuation-based web programming, too. It might be good source
> for ideas.
>
> --Kevin
>
> On Feb 13, 2008, at 9:12 PM, jm wrote:
>
> >
> > macrocreation wrote:
> >> Yariv,
> >>
> >> I suggest you have a look at seaside. Continuations not only make the
> >> code development easy, but you can suddenly start to develop "true"
> >> components and they are straightforwardly embeddable - the complexity
> >> of mixing and matching components becomes additive rather the
> >> geometric if that makes sense.
> >
> > This is the argument I've heard in favor of it as well.
> >
> > The bit that made the most sense to me why you'd want to do this is
> > not
> > the reduction in code size (I don't think there is), but the ability
> > to
> > think and code dirictly in a process flow manner instead of a finite
> > state machine's transitions. FSMs cause problems as they grow larger
> > and
> > more complex as it gets harder to fit it all in one's head at the
> > sametime.
> >
> > Consider this bad ASCII art, adopted from "Inverting back the
> > inversion
> > of control or, Continuations versus page-centric programming"
> >
> > get post post
> > ----->[get num1]----->[get num2]---->[display num1 + num2]
> >
> >
> > using the current erlyweb we'd have something like, ignoring error
> > cases,
> >
> > -module(traditional)
> >
> >
> > add(A) ->
> > case Method of
> > 'GET' ->
> > generate_num1_form(A);
> > 'POST' ->
> > F = get_fields_from_form(A),
> > %% uses client to store num1 as hidden field in 2nd form
> > case proplists:lookup(num1, F) of
> > none -> {ewr, traditional, add};
> > N1 -> case proplists:lookup(num2) of
> > none -> generate_num2_form(A, N1);
> > N2 -> generate_sum_page(A, N1, N2)
> > end
> > end
> > end.
> >
> >
> > What would this look like in an Erlang/Erlyweb with continuation? I'll
> > leave this for someone else as this what I'm trying to work out. In
> > psuedo code
> >
> > add(A) ->
> > N1 = get_num1(A),
> > N2 = get_num2(A),
> > generate_sum_page(A, N1, N2).
> >
> >
> > get_num1(A) ->
> > generate_num1_form(A),
> > break/resume
> > F = get_fields_from_form(A),
> > proplists:lookup(num1, F).
> >
> >
> > get_num2(A) ->
> > generate_num2_form(A),
> > break/resume
> > F = get_fields_from_form(A),
> > proplists:lookup(num2, F).
> >
> >
> > which is really just the previous code turned inside out. The bit I'm
> > stumbling on at the moment is error control and branching of flow
> > (case/if) and how it fits into this.
> >
> > Regardless, I can't understand why continuations would use so much
> > memory. The only things I can think of are
> > 1) The estimate I heard was wrong.
> > 2) The estimate I heard was for large applications
> > 3) This is due to saving the full stack for each call (post/get) and
> > then keeping the old stacks around for a long time.
> >
> > I keep seeing not stacks but changes in state forming a tree of
> > changes.
> > ie, erlyweb taking snapshots of the values of functions at the
> > break/resume points but not the entire stack and these for the node
> > of a
> > state tree in time.
> >
> > Lasty, thanks to k.parnell@gmail.com for recommending a couple of
> > papers
> > I'm only half through the first one as I'm not formilar with scheme.
> > In
> > searching I also found this archived message which seems to indicate
> > some relevent papers,
> >
> > http://www.cs.brown.edu/pipermail/plt-scheme/2007-April/017628.html
> >
> > Jeff.
> >
> >> I can't explain the gist of my argument - its one of those matrix
> >> things - when it sinks in you go "Wow!".
> >>
> >> Why am I still programming in erlang? I really like the scalability
> >> and a lot of my applications need lots of concurrent processes.
> >>
> >> I have been told any system that supports first class function
> >> objects
> >> with lexical closure is able to support continuation passing style
> >> - I
> >> think it would even be easier with erlang considering you don't have
> >> to worry about variable mutations and the like.
> >>
> >> hafeez
> >>
> >>
> >> On Feb 13, 8:32 pm, "Yariv Sadan" <yarivsa...@gmail.com> wrote:
> >>> Dang, I actually realized I just overlooked something big: my
> >>> examples
> >>> didn't use real closures -- just anonymous functions. With framework
> >>> support, those functions could be used as closures and their
> >>> environment data could be accessible in subsequent actions without
> >>> the
> >>> controller's using the session store explicitly. I should have
> >>> thought
> >>> a bit harder before voicing my skepticism (However, I believe
> >>> some
> >>> of the disadvantages I listed still hold true.)
> >>>
> >>> Yariv
> >>>
> >>> On Feb 12, 2008 10:35 PM, Yariv Sadan <yarivsa...@gmail.com> wrote:
> >>>
> >
> >
> > >
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "erlyweb" group.
To post to this group, send email to erlyweb@googlegroups.com
To unsubscribe from this group, send email to erlyweb-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/erlyweb?hl=en
-~----------~----~----~----~------~----~------~--~---
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Mon Feb 18, 2008 6:00 am |
|
|
|
Guest
|
|
| Back to top |
|
| Guest |
| Posted: Tue Feb 19, 2008 8:55 am |
|
|
|
Guest
|
>
> Only had time for a quick read. Sounds something like
> http://code.google.com/p/spewf/
Yeah, it looks similar in the way it uses processes for user sessions.
Unfortunately, the documentation doesn't say much about how to use it
to build full apps.
>
> > On Feb 15, 2008 8:47 PM, Kevin A. Smith <kevin@hypotheticalabs.com> wrote:
> >> This paper:
> >>
> >> http://siscweb.sourceforge.net/docs/queinnec-inverting.pdf
> >>
> >> helped me have the "aha!" moment using continuations and the web. If
> >> you're comfortable reading Scheme, siscweb has a decent implementation
> >> of continuation-based web programming, too. It might be good source
> >> for ideas.
> >>
>
> This is the paper, which for me, finally explained why you'd want to do
> this clearly and provides good simple examples which could be used as
> test cases.
>
> Jeff.
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "erlyweb" group.
To post to this group, send email to erlyweb@googlegroups.com
To unsubscribe from this group, send email to erlyweb-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/erlyweb?hl=en
-~----------~----~----~----~------~----~------~--~---
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Thu Feb 21, 2008 4:48 am |
|
|
|
Guest
|
Yariv Sadan wrote:
> Yeah, it looks similar in the way it uses processes for user sessions.
> Unfortunately, the documentation doesn't say much about how to use it
> to build full apps.
I know your code is really only a proof of concept, but I noticed that
your gen_key() function doesn't test for key collisions. The code I've
been testing is a little more complicated. It walks the mnesia table to
find the max id and adds one then encodes to/from a modified base64. The
modification to base64 is to replace $+ with $- and $/ with $_.
Encryption/decryption of the integer id is added to avoid making the ids
guessable, but this is frankly all a little heavy handed.
I wont post all the code as there's about three or four versions/ways of
doing things in the same file and not all of it works at the moment as I
keep changing my mind on how to approach problems. Anyway, use anything
that's proves useful.
Really it comes down to how likely a key/id collision is and how to
guarrantee that a unique key can be generated in near O(1) time for a
large number of sessions.
Jeff.
-------------
%% creates a new state record with a unique id
new(SessionId, OldId) when OldId =:= undefined orelse is_integer(OldId) ->
Now = now(),
F = fun() ->
MaxId = mnesia:foldl(fun(Elem, Max) ->
case Elem#wstate.id of
M when M > Max -> M;
_ -> Max
end
end, 0, wstate),
WS = #wstate{id = MaxId + 1,
session_id = SessionId,
proceededby = OldId,
created = Now,
last_touched = Now,
values = undefined
},
mnesia:write(wstate, WS, write),
WS
end,
{atomic, Rec} = mnesia:transaction(F),
Rec.
%% Given the numeric id encodes for use in web pages.
encode(undefined) ->
undefined;
encode(Id) ->
IdBin = <<Id:128/integer-big>>,
IVec = crypto:rand_bytes(16),
IdCrypt = crypto:aes_cbc_128_encrypt(?KEY, IVec, IdBin),
MagicStr = <<IVec/binary, IdCrypt/binary>>,
B64 = http_base_64:encode(binary_to_list(MagicStr)),
sub_slash_and_plus(B64).
sub_slash_and_plus(Str) when is_list(Str) ->
lists:map(fun(Elem) ->
case Elem of
$+ -> $-;
$/ -> $_;
L -> L
end
end, Str).
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "erlyweb" group.
To post to this group, send email to erlyweb@googlegroups.com
To unsubscribe from this group, send email to erlyweb-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/erlyweb?hl=en
-~----------~----~----~----~------~----~------~--~---
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Thu Feb 21, 2008 12:21 pm |
|
|
|
Guest
|
> length(lists:seq($a, $z) ++ lists:seq($A, $Z) ++ lists:seq($0, $9)).
62
> math:pow(62,10).
8.39299e+17
Mmm, very little chance of collision in the original algorithm.
gen_key() ->
F = fun() ->
choose_key(5)
end,
mensia:transaction(F)
choose_key(0) ->
%% time to panic
undefined;
choose_key(Count) when is_integer(Count) ->
Chars = lists:seq($a, $z) ++ lists:seq($A, $Z) ++ lists:seq($0, $9),
Key = [lists:nth(crypto:rand_uniform(1, length(Chars)), Chars) ||
N <- lists:seq(1, 10)],
case mnesia:read(cont, Key, read) of
[] ->
%% choose again
choose_key(Count - 1);
[_ContRec] ->
Key
end.
Just thinking about edge cases and what would be the correct course of
action when a key collision occurs.
Jeff.
jm wrote:
> Yariv Sadan wrote:
>
>> Yeah, it looks similar in the way it uses processes for user sessions.
>> Unfortunately, the documentation doesn't say much about how to use it
>> to build full apps.
>
> I know your code is really only a proof of concept, but I noticed that
> your gen_key() function doesn't test for key collisions. The code I've
> been testing is a little more complicated. It walks the mnesia table to
> find the max id and adds one then encodes to/from a modified base64. The
> modification to base64 is to replace $+ with $- and $/ with $_.
> Encryption/decryption of the integer id is added to avoid making the ids
> guessable, but this is frankly all a little heavy handed.
>
> I wont post all the code as there's about three or four versions/ways of
> doing things in the same file and not all of it works at the moment as I
> keep changing my mind on how to approach problems. Anyway, use anything
> that's proves useful.
>
> Really it comes down to how likely a key/id collision is and how to
> guarrantee that a unique key can be generated in near O(1) time for a
> large number of sessions.
>
>
> Jeff.
> -------------
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "erlyweb" group.
To post to this group, send email to erlyweb@googlegroups.com
To unsubscribe from this group, send email to erlyweb-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/erlyweb?hl=en
-~----------~----~----~----~------~----~------~--~---
Post recived from mailinglist |
|
|
| Back to top |
|
|
|
All times are GMT
Page 1 of 2
Goto page 1, 2 Next
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum
|
|
|
Digg It
Del.icio.us
Reddit
Facebook
Stumble Upon
Technorati
