| Author |
Message |
|
| Willem |
 Posted: Thu Nov 29, 2007 9:00 pm |
 |
|
|
User
Joined: 21 Jul 2006
Posts: 59
|
Hi,
A couple of days ago Dave M. pointed out that ErlyWeb could benefit
from
a web services framework (in the thread about Strenghts and
Weaknesses).
I would be willing to try to improve this, but I would like some
guidance: what
should it do?
I will probably use the existing yaws+erlsom implication as a basis,
but I agree that it
can be improved. In particular the set-up could be easier.
- I already have some code available that improves the handling of
import statements.
- What flavours of webservices should be supported? Currently we have
the
'document/literal' type only.
- What type of interoperability issues should I be aware of?
- Should there be a strong link to the rest of erlyweb? What should it
look like? Or would
it be sufficient to offer support for web services in YAWS in a nice
way? The handlers could
call the ErlyDB APIs, of course.
- Should there be a generic framework that also covers XMLRPC, REST,
Json? Is there an
example of such a framework - maybe in Ruby? I can imagine something
generic for all the
XML based variants, but I struggle for JSON. Not because it is not
XML, but because there
appears to be no 'schema' for JSON. It seems to me that such a
framework would require
some kind of metadata/specification, like a schema or WSDL.
- anything else?
Regards,
Willem
--~--~---------~--~----~------------~-------~--~----~
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 Nov 29, 2007 9:25 pm |
|
|
|
Guest
|
Hello everyone,
Responses within Willem's text...
On 30/11/2007, Willem de Jong <w.a.de.jong@gmail.com> wrote:
>
> Hi,
>
> A couple of days ago Dave M. pointed out that ErlyWeb could benefit
> from
> a web services framework (in the thread about Strenghts and
> Weaknesses).
>
> I would be willing to try to improve this, but I would like some
> guidance: what
> should it do?
>
> I will probably use the existing yaws+erlsom implication as a basis,
> but I agree that it
> can be improved. In particular the set-up could be easier.
>
> - I already have some code available that improves the handling of
> import statements.
>
> - What flavours of webservices should be supported? Currently we have
> the
> 'document/literal' type only.
From my perspective, the most important would be SOAP and XML-RPC,
with others such as JSON and REST well behind those two.
The reason is that SOAP is pretty much *the* standard interface for
developers working in the WebSphere/J2EE and .NET arenas. If we want
to push Erlang into the "enterprise" (and I use that term loosely)
areas, then it really has to be able to work with WebSphere and .NET;
if not, the "default" solution of "forget this Erlang stuff; we'll
just build it in our normal toolset" becomes a lot more difficult to
counter.
In general, for people working with J2EE and .NET, REST is probably on
the very edge of their perception. Obviously that's a sweeping
statement, but the reality is that J2EE and .NET have pushed SOAP (and
to a lesser extent XML-RPC) as *the* Web service solution for many
years, and as yet there's been no push from the key software vendors
to entice people to even look for something beyond those protocols.
From an individual developer's perspective, there's no incentive
(beyond professional curiosity) to even look beyond SOAP when
everything you work with daily already talks SOAP?
Personally, I see REST in particular as a big step forward, but in my
corporate experience that's not a common perception.
>
> - What type of interoperability issues should I be aware of?
>
> - Should there be a strong link to the rest of erlyweb? What should it
> look like? Or would
> it be sufficient to offer support for web services in YAWS in a nice
> way? The handlers could
> call the ErlyDB APIs, of course.
Personally, I'd like it to be hooked to Erlyweb rather than to Yaws -
I think the MVC model in Erlyweb hits a very big sweetspot, and
Erlyweb would be my choice (rather than Yaws) as the base platform for
most Erlang Web development at this point.
However, it's obviously early (erly?) days for Erlyweb yet, so I'm not
particularly locked in on this thinking at this point. I'm sure there
would be benefits in hooking to Yaws instead of Erlyweb that I haven't
considered.
Has anyone else got any thoughts on this?
>
> - Should there be a generic framework that also covers XMLRPC, REST,
> Json? Is there an
> example of such a framework - maybe in Ruby?
Ruby on Rails (RoR) has a framework that covers SOAP and XML-RPC
(Active WebService); basically it takes about 10 minutes to implement
it on top of your existing functionality, so it's trivial to add a Web
services interface for these protocols to your existing (HTML)
application.
RoR seems to moving towards deprecating Active WebService (AWS) in
place of a REST interface; I suspect the reasoning is that relatively
few people are using AWS as RoR seems to be targetting standalone
applications in startups as their key market, and REST is conceptually
easier to understand and implement when you're not having to interface
with J2EE and .NET apps. Personally, I've found RoR gets huge
acceptance all over the place purely for the reduced development time;
it doesn't scale that well (or more accurately, it becomes expensive
to scale it), but the vast majority of apps in big companies don't
need to scale to big numbers of users. If I can have a demo RoR app
built that's 90% functional while the J2EE and .NET guys are still
working out which versions of their various libraries will work
together, that's a pretty major selling point right there.
I can imagine something
> generic for all the
> XML based variants, but I struggle for JSON. Not because it is not
> XML, but because there
> appears to be no 'schema' for JSON. It seems to me that such a
> framework would require
> some kind of metadata/specification, like a schema or WSDL.
Personally, I think it would be harder to create a generic JSON
solution than for the other protocols, for the reason you've outlined
- there's no commonly-agreed schema. There is for SOAP and XML-RPC,
and REST has a "sort of, defacto" agreed mapping to the general CRUD
database access model.
If you tried to create a generic JSON solution, I can't see how you
could avoid defining your own schema, and then users would have to
build tools that talk to your schema specifically. My guess is that,
in that case, an IBM/Microsoft/Sun/... would almost inevitably come
out with a completely different "standard" schema within the next
month ;->
>
> - anything else?
No, that's about all I can think of at this point. Now I'd better
hustle off to work - I'm gonna be late...
Thanks for your response
Dave M.
>
> Regards,
> Willem
> >
>
--~--~---------~--~----~------------~-------~--~----~
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: Sun Dec 02, 2007 1:24 am |
|
|
|
Guest
|
>
> From my perspective, the most important would be SOAP and XML-RPC,
> with others such as JSON and REST well behind those two.
>
> The reason is that SOAP is pretty much *the* standard interface for
> developers working in the WebSphere/J2EE and .NET arenas. If we want
> to push Erlang into the "enterprise" (and I use that term loosely)
> areas, then it really has to be able to work with WebSphere and .NET;
> if not, the "default" solution of "forget this Erlang stuff; we'll
> just build it in our normal toolset" becomes a lot more difficult to
> counter.
>
> In general, for people working with J2EE and .NET, REST is probably on
> the very edge of their perception. Obviously that's a sweeping
> statement, but the reality is that J2EE and .NET have pushed SOAP (and
> to a lesser extent XML-RPC) as *the* Web service solution for many
> years, and as yet there's been no push from the key software vendors
> to entice people to even look for something beyond those protocols.
> From an individual developer's perspective, there's no incentive
> (beyond professional curiosity) to even look beyond SOAP when
> everything you work with daily already talks SOAP?
>
> Personally, I see REST in particular as a big step forward, but in my
> corporate experience that's not a common perception.
Do you think the "enterprise" would accept Erlang/ErlyWeb as a
platform for web services development, though? I was under the
impression that most "enterprises" use .NET and Java because it's
easiest to recruit engineers who know those languages. Would the CTOs
of such companies consider ErlyWeb just because it performs better
than Rails? (The performance difference is hypothetical -- I haven't
seen any benchmarks to base it on.)
>
> >
> > - What type of interoperability issues should I be aware of?
> >
> > - Should there be a strong link to the rest of erlyweb? What should it
> > look like? Or would
> > it be sufficient to offer support for web services in YAWS in a nice
> > way? The handlers could
> > call the ErlyDB APIs, of course.
>
> Personally, I'd like it to be hooked to Erlyweb rather than to Yaws -
> I think the MVC model in Erlyweb hits a very big sweetspot, and
> Erlyweb would be my choice (rather than Yaws) as the base platform for
> most Erlang Web development at this point.
>
> However, it's obviously early (erly?) days for Erlyweb yet, so I'm not
> particularly locked in on this thinking at this point. I'm sure there
> would be benefits in hooking to Yaws instead of Erlyweb that I haven't
> considered.
I'm not sure that a web services implementation needs all the MVC
capabilities that ErlyWeb provices, but the 'M' should certainly be
useful, and maybe also the 'C'. Mapping incoming requests to ErlyWeb
controller functions would be elegant I think, but ErlyDB would
certainly be useful for someone who's building web services
>
> Has anyone else got any thoughts on this?
>
> >
> > - Should there be a generic framework that also covers XMLRPC, REST,
> > Json? Is there an
> > example of such a framework - maybe in Ruby?
>
> Ruby on Rails (RoR) has a framework that covers SOAP and XML-RPC
> (Active WebService); basically it takes about 10 minutes to implement
> it on top of your existing functionality, so it's trivial to add a Web
> services interface for these protocols to your existing (HTML)
> application.
>
> RoR seems to moving towards deprecating Active WebService (AWS) in
> place of a REST interface; I suspect the reasoning is that relatively
> few people are using AWS as RoR seems to be targetting standalone
> applications in startups as their key market, and REST is conceptually
> easier to understand and implement when you're not having to interface
> with J2EE and .NET apps. Personally, I've found RoR gets huge
> acceptance all over the place purely for the reduced development time;
> it doesn't scale that well (or more accurately, it becomes expensive
> to scale it), but the vast majority of apps in big companies don't
> need to scale to big numbers of users. If I can have a demo RoR app
> built that's 90% functional while the J2EE and .NET guys are still
> working out which versions of their various libraries will work
> together, that's a pretty major selling point right there.
If ErlyWeb scales as well as or better than J2EE (it's possible!) and
lets you develop as rapidly as Rails (if you know Erlang  ), maybe
it would hit a sweet spot.
"ErlyWeb = enterprise scalability + agile development". If we only had
a marketing budget...
>
> I can imagine something
> > generic for all the
> > XML based variants, but I struggle for JSON. Not because it is not
> > XML, but because there
> > appears to be no 'schema' for JSON. It seems to me that such a
> > framework would require
> > some kind of metadata/specification, like a schema or WSDL.
>
> Personally, I think it would be harder to create a generic JSON
> solution than for the other protocols, for the reason you've outlined
> - there's no commonly-agreed schema. There is for SOAP and XML-RPC,
> and REST has a "sort of, defacto" agreed mapping to the general CRUD
> database access model.
>
> If you tried to create a generic JSON solution, I can't see how you
> could avoid defining your own schema, and then users would have to
> build tools that talk to your schema specifically. My guess is that,
> in that case, an IBM/Microsoft/Sun/... would almost inevitably come
> out with a completely different "standard" schema within the next
> month ;->
I don't think you necessarily need a generic JSON solution, but an
ErlyWeb-specific one would be useful for ErlyWeb developers.
Applications often make AJAX calls to a backend controller that
returns JSON. I think it would be useful to support Erlang -> JSON
serialization in the framework. Ideally, you could write your code
generically and let the Framework serialize it for you based on the
protocol. For example, the following response could be easily
translated to JSON (and maybe other protocols) without needing a
"standard" schema type:
-module(api_controller).
-compile(export_all).
foo(A, Param1, Param2) ->
{rpc, [1, 2, 3, <<"foo">>, <<"bar">>, {dict, [{a, {string, "b"}},
{c, {string, "d"}}]}]}.
Any thoughts?
Yariv
--~--~---------~--~----~------------~-------~--~----~
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: Sun Dec 02, 2007 5:32 am |
|
|
|
Guest
|
G'day Yariv,
On 02/12/2007, Yariv Sadan <yarivsadan@gmail.com> wrote:
>
> >
> > From my perspective, the most important would be SOAP and XML-RPC,
> > with others such as JSON and REST well behind those two.
> >
> > The reason is that SOAP is pretty much *the* standard interface for
> > developers working in the WebSphere/J2EE and .NET arenas. If we want
> > to push Erlang into the "enterprise" (and I use that term loosely)
> > areas, then it really has to be able to work with WebSphere and .NET;
> > if not, the "default" solution of "forget this Erlang stuff; we'll
> > just build it in our normal toolset" becomes a lot more difficult to
> > counter.
> >
> > In general, for people working with J2EE and .NET, REST is probably on
> > the very edge of their perception. Obviously that's a sweeping
> > statement, but the reality is that J2EE and .NET have pushed SOAP (and
> > to a lesser extent XML-RPC) as *the* Web service solution for many
> > years, and as yet there's been no push from the key software vendors
> > to entice people to even look for something beyond those protocols.
> > From an individual developer's perspective, there's no incentive
> > (beyond professional curiosity) to even look beyond SOAP when
> > everything you work with daily already talks SOAP?
> >
> > Personally, I see REST in particular as a big step forward, but in my
> > corporate experience that's not a common perception.
>
> Do you think the "enterprise" would accept Erlang/ErlyWeb as a
> platform for web services development, though? I was under the
> impression that most "enterprises" use .NET and Java because it's
> easiest to recruit engineers who know those languages. Would the CTOs
> of such companies consider ErlyWeb just because it performs better
> than Rails? (The performance difference is hypothetical -- I haven't
> seen any benchmarks to base it on.)
I don't know if "the enterprise" is ready to accept Erlang/ErlyWeb,
but I think there's a growing realisation that Java and C# aren't the
answer to every programming question. Java now runs acceptably fast,
but as soon as your code starts to spawn threads off it starts to get
ugly.
C# is pretty much in the same ballpark
There's also the case that the languages themselves aren't necessarily
the best fit for a large range of problems. In two big companies
where I've worked, there's a dawning understanding of two issues: (a)
the cost of buggy code is just way too high, (b) the cost of securing
sensitive code against buffer overflows and the like is also extremely
high; functional languages remove a large part of the opportunity for
these two problems to arise.
I don't necessarily think Erlang/ErlyWeb are going to get significant
enterprise mindshare, but I think that something other than Java and
C# will, very soon.
>
>
> >
> > >
> > > - What type of interoperability issues should I be aware of?
> > >
> > > - Should there be a strong link to the rest of erlyweb? What should it
> > > look like? Or would
> > > it be sufficient to offer support for web services in YAWS in a nice
> > > way? The handlers could
> > > call the ErlyDB APIs, of course.
> >
> > Personally, I'd like it to be hooked to Erlyweb rather than to Yaws -
> > I think the MVC model in Erlyweb hits a very big sweetspot, and
> > Erlyweb would be my choice (rather than Yaws) as the base platform for
> > most Erlang Web development at this point.
> >
> > However, it's obviously early (erly?) days for Erlyweb yet, so I'm not
> > particularly locked in on this thinking at this point. I'm sure there
> > would be benefits in hooking to Yaws instead of Erlyweb that I haven't
> > considered.
>
> I'm not sure that a web services implementation needs all the MVC
> capabilities that ErlyWeb provices, but the 'M' should certainly be
> useful, and maybe also the 'C'. Mapping incoming requests to ErlyWeb
> controller functions would be elegant I think, but ErlyDB would
> certainly be useful for someone who's building web services
>
With Ruby on Rails, the M and C do what you'd expect; the V's job is
to format what C hands to it. In a Web services context, that means
that (typically) V's job is to take a hierarchical collection of
objects from C, and deliver it in the appropriate sequence or with the
appropriate format.
For example, C might return a set of authors, and under that, the set
of books they've written, ISBNs and so on. The V might present it as
<authors>
<author name=>
<book title=>
<isbn id=>
but a different V might present the same info as
<books>
<book title=>
<author name=>
<isbn id=>
In essence, the V layer can be used to juggle the hierarchy of data
given it to by C. I realise this could all be done in C, but then you
might wind up with multiple C layers to present identical data in
different ways; Rails uses multiple V layers instead, and gives a
domain-specific language (RXML) to allow you to tweak data as per the
above in a very simple manner. Extending and maintaining RXML code is
particularly simple.
I like the way this works in Rails, but in the end it's a syntactic
sugar more than a must-have feature.
>
> >
> > Has anyone else got any thoughts on this?
> >
> > >
> > > - Should there be a generic framework that also covers XMLRPC, REST,
> > > Json? Is there an
> > > example of such a framework - maybe in Ruby?
> >
> > Ruby on Rails (RoR) has a framework that covers SOAP and XML-RPC
> > (Active WebService); basically it takes about 10 minutes to implement
> > it on top of your existing functionality, so it's trivial to add a Web
> > services interface for these protocols to your existing (HTML)
> > application.
> >
> > RoR seems to moving towards deprecating Active WebService (AWS) in
> > place of a REST interface; I suspect the reasoning is that relatively
> > few people are using AWS as RoR seems to be targetting standalone
> > applications in startups as their key market, and REST is conceptually
> > easier to understand and implement when you're not having to interface
> > with J2EE and .NET apps. Personally, I've found RoR gets huge
> > acceptance all over the place purely for the reduced development time;
> > it doesn't scale that well (or more accurately, it becomes expensive
> > to scale it), but the vast majority of apps in big companies don't
> > need to scale to big numbers of users. If I can have a demo RoR app
> > built that's 90% functional while the J2EE and .NET guys are still
> > working out which versions of their various libraries will work
> > together, that's a pretty major selling point right there.
>
> If ErlyWeb scales as well as or better than J2EE (it's possible!) and
> lets you develop as rapidly as Rails (if you know Erlang ), maybe
> it would hit a sweet spot.
>
> "ErlyWeb = enterprise scalability + agile development". If we only had
> a marketing budget...
I strongly suspect ErlyWeb could scale far better than J2EE for some
specific use cases. Erlang's ability to create new processes quickly
(not to mention simply) gives it an advantage that must have some
benefits...
>
> >
> > I can imagine something
> > > generic for all the
> > > XML based variants, but I struggle for JSON. Not because it is not
> > > XML, but because there
> > > appears to be no 'schema' for JSON. It seems to me that such a
> > > framework would require
> > > some kind of metadata/specification, like a schema or WSDL.
> >
> > Personally, I think it would be harder to create a generic JSON
> > solution than for the other protocols, for the reason you've outlined
> > - there's no commonly-agreed schema. There is for SOAP and XML-RPC,
> > and REST has a "sort of, defacto" agreed mapping to the general CRUD
> > database access model.
> >
> > If you tried to create a generic JSON solution, I can't see how you
> > could avoid defining your own schema, and then users would have to
> > build tools that talk to your schema specifically. My guess is that,
> > in that case, an IBM/Microsoft/Sun/... would almost inevitably come
> > out with a completely different "standard" schema within the next
> > month ;->
>
> I don't think you necessarily need a generic JSON solution, but an
> ErlyWeb-specific one would be useful for ErlyWeb developers.
> Applications often make AJAX calls to a backend controller that
> returns JSON. I think it would be useful to support Erlang -> JSON
> serialization in the framework. Ideally, you could write your code
> generically and let the Framework serialize it for you based on the
> protocol. For example, the following response could be easily
> translated to JSON (and maybe other protocols) without needing a
> "standard" schema type:
>
> -module(api_controller).
> -compile(export_all).
>
> foo(A, Param1, Param2) ->
> {rpc, [1, 2, 3, <<"foo">>, <<"bar">>, {dict, [{a, {string, "b"}},
> {c, {string, "d"}}]}]}.
>
>
> Any thoughts?
Yep, I can see how that makes sense. I haven't really used JSON in
any non-learning context, so I'm still coming to grips with how/where
I should be using it. I've had a bit of a prejudice against
JavaScript as a "toy" language for years, and now I'm finding I have
to unlearn that prejudice.
Smarter people than me could probably give some better advice in this area.
Regards
Dave M.
>
> Yariv
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
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: Sun Dec 02, 2007 10:16 pm |
|
|
|
Guest
|
>
> I don't know if "the enterprise" is ready to accept Erlang/ErlyWeb,
> but I think there's a growing realisation that Java and C# aren't the
> answer to every programming question. Java now runs acceptably fast,
> but as soon as your code starts to spawn threads off it starts to get
> ugly.
>
> C# is pretty much in the same ballpark
I think a big issue with Java, C#, etc as far as concurrency goes
isn't just the shared memory issues but also that those languages make
programmers afraid (justifiably so) of spawning threads whenever they
needs them. This leads to the creation of threadpools, whose min/max
numbers of threads are usually arbitrary ("yeah, 20 threads should be
just fine for my app! I think...") and which cause bottlenecks that
are hard to identify. If you're building a desktop app that does a few
things in the background, that's probably ok, but for scalable,
reliable servers it's a big disadvantage.
>
> There's also the case that the languages themselves aren't necessarily
> the best fit for a large range of problems. In two big companies
> where I've worked, there's a dawning understanding of two issues: (a)
> the cost of buggy code is just way too high, (b) the cost of securing
> sensitive code against buffer overflows and the like is also extremely
> high; functional languages remove a large part of the opportunity for
> these two problems to arise.
>
> I don't necessarily think Erlang/ErlyWeb are going to get significant
> enterprise mindshare, but I think that something other than Java and
> C# will, very soon.
Yeah, I agree. It's hard to estimate how much adoption Erlang will
have in the enterprise even if it is a better tool that what is used
currently. The problem is the training of programmers who don't know
Erlang. I actually think that Erlang is easy to learn (I often tell
people that it would be easier for me to teach Erlang than Java to
someone who knows nothing about programming) but maybe I've been using
it for too long
Who knows -- maybe Joe Armstrong's book will tip the balance in
Erlang's favor. And one or two successful Erlang startups
(MochiMedia?).
>
> With Ruby on Rails, the M and C do what you'd expect; the V's job is
> to format what C hands to it. In a Web services context, that means
> that (typically) V's job is to take a hierarchical collection of
> objects from C, and deliver it in the appropriate sequence or with the
> appropriate format.
>
> For example, C might return a set of authors, and under that, the set
> of books they've written, ISBNs and so on. The V might present it as
> <authors>
> <author name=>
> <book title=>
> <isbn id=>
> but a different V might present the same info as
> <books>
> <book title=>
> <author name=>
> <isbn id=>
>
> In essence, the V layer can be used to juggle the hierarchy of data
> given it to by C. I realise this could all be done in C, but then you
> might wind up with multiple C layers to present identical data in
> different ways; Rails uses multiple V layers instead, and gives a
> domain-specific language (RXML) to allow you to tweak data as per the
> above in a very simple manner. Extending and maintaining RXML code is
> particularly simple.
>
> I like the way this works in Rails, but in the end it's a syntactic
> sugar more than a must-have feature.
I think that the main difference between web services and web apps is
that in web services, the framework can do the rendering for you
automatically based on the input data (the controller function return
value) and the protocol flag. I think it would be less efficient to
let the data undergo another transformation in the view layer -- why
not just serve it from the controller in the form in which it needs to
be consumed?
> >
> > "ErlyWeb = enterprise scalability + agile development". If we only had
> > a marketing budget...
>
> I strongly suspect ErlyWeb could scale far better than J2EE for some
> specific use cases. Erlang's ability to create new processes quickly
> (not to mention simply) gives it an advantage that must have some
> benefits...
I think so too. It would be interesting to see some real benchmarks
comparing Erlang/ErlyWeb against Rails and J2EE. I'm not sure what the
page render time difference will be under light load, but I think what
we'll see is that both J2EE and Rails crash at a relatively low number
of concurrenct requests but ErlyWeb keeps on serving them, albeit
somewhat slower at heavy load.
>
> Yep, I can see how that makes sense. I haven't really used JSON in
> any non-learning context, so I'm still coming to grips with how/where
> I should be using it. I've had a bit of a prejudice against
> JavaScript as a "toy" language for years, and now I'm finding I have
> to unlearn that prejudice.
It may be a toy language, but it made Google (and other companies) a
lot of money
Yariv
--~--~---------~--~----~------------~-------~--~----~
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
|
|
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
