Happstack website design and brand identity -- an offer to help out
James Fisher
went anywhere -- if it did, apologies for double posting. This via
the webform:)
Hi all,
I've recently become an avid Haskell fan, and the first thing I like
to become familiar with in a new language is its status for web
development. With a little research, it seems Happstack is the
leading framework and community for this. However, IMO the visual
identity of Happstack suggests strongly otherwise:
* The page at http://happstack.com/index.html has an extremely
template-y feel. The same goes for http://tutorial.happstack.com/ --
automatic logo creation is the spawn of the devil.
* http://happstack.com/ doesn't sell itself at all -- a new
prospective user doesn't want to know that "The Happstack project
needs you!", she wants to know what Happstack is and why she should
use it, in a concise jargon-free manner.
* happstack.com and tutorial.happstack don't complement each other at
all. The Haddock documentation is different again. The wordpress
blog is different again.
I could go on. In short I invite you to compare Happstack's web
identity to any of the following:
http://rubyonrails.org/
http://www.djangoproject.com/
http://grok.zope.org/
http://www.sinatrarb.com/
http://www.sproutcore.com/
http://www.seaside.st/
http://vaadin.com/home
But I'd like to help rather than criticize. Does Happstack currently
have any identity documents? A logo of some sort? Color palette?
These are the kind of things I'd like to get involved with.
Best,
James Fisher
--
You received this message because you are subscribed to the Google Groups "HAppS" group.
To post to this group, send email to ha...@googlegroups.com.
To unsubscribe from this group, send email to happs+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/happs?hl=en.
James Fisher
James
James Fisher
Jeremy Shaw
Hi all,
I've recently become an avid Haskell fan, and the first thing I like to become familiar with in a new language is its status for web development. With a little research, it seems Happstack is the leading framework and community for this. However, IMO the visual identity of Happstack suggests strongly otherwise:
* The page at http://happstack.com/index.html has an extremely template-y feel. The same goes for http://tutorial.happstack.com/ -- automatic logo creation is the spawn of the devil.
* http://happstack.com/ doesn't sell itself at all -- a new prospective user doesn't want to know that "The Happstack project needs you!", she wants to know what Happstack is and why she should use it, in a concise jargon-free manner.
* happstack.com and tutorial.happstack don't complement each other at all. The Haddock documentation is different again. The wordpress blog is different again.
I could go on. In short I invite you to compare Happstack's web identity to any of the following:
But I'd like to help rather than criticize. Does Happstack currently have any identity documents? A logo of some sort? Color palette? These are the kind of things I'd like to get involved with.
James Fisher
Yes. happstack.com was autogenerated by a template, and later converted to happstack+HSP. But it is still just the output of a free site generator template.
Thought so.
* http://happstack.com/ doesn't sell itself at all -- a new prospective user doesn't want to know that "The Happstack project needs you!", she wants to know what Happstack is and why she should use it, in a concise jargon-free manner.
Indeed. I think Matthew just typed that up in a hurry when he launched the site, and it has never really been updated (as from fixing some typos).
Selling points could be profitably harvested from the tutorial I think.
On a related note, I have been asked to contribute an entry for happstack to HCAR.
HCAR? I'm not familiar (in new territory here).
So it would be good to come up with a better sales letter by May 1, and then use that on the site as well perhaps.* happstack.com and tutorial.happstack don't complement each other at all. The Haddock documentation is different again. The wordpress blog is different again.
Yes. I think the tutorial may even predate happstack itself :) The wordpress blog is not really maintained at the moment. Only matthew elder has posting permissions and he is temporarily out of service while raising a baby.
A better excuse than most.
It might be cool to theme the haddock stuff -- not sure if anyone has ever tried that. We just use whatever haddock spits out.
I had wondered that. Can't be too hard to just inject a CSS reference though. (Though I notice it spits out the most god-awful tables... maybe that's something I could work on sometime.)
So, the possible things to unify would be:our facebook pageour twitter pagethe documentationI could go on. In short I invite you to compare Happstack's web identity to any of the following:
No need :)But I'd like to help rather than criticize. Does Happstack currently have any identity documents? A logo of some sort? Color palette? These are the kind of things I'd like to get involved with.
At present, no. However, after the release of 0.5 (this week hopefully),
My breath is bated.
documentation is going to be the primary focus. Unifying the identity and branding is a highly complementary task. So, good timing :)The author of this logo suggested we use it for happstack,
Hmmm ... :) it's certainly striking. I do love playing with pen and ink. A pen-and-ink--based brand image would be really cool if done right. Perhaps I'll play around with that.
--I am rather fond of it, but I have not yet come up with a description of why it represents happstack :)The only thing I am especially attached to about the current site is that it is (1) actually powered by happstack (2) the source is available via a public darcs repo so that people can submit patches:I would like to retain those two aspects. I would prefer to stick with darcs/patch-tag because that is what we already use for everything else. (And patch-tag is written in happstack, so we like to support it).What is the next step? Perhaps it is defining happstack with out using any buzzwords?- jeremyYou received this message because you are subscribed to the Google Groups "HAppS" group.
To post to this group, send email to ha...@googlegroups.com.
To unsubscribe from this group, send email to happs+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/happs?hl=en.
James Fisher
Thoughts?
Conrad Parker
> Hi all -- if you're interested, I've been playing with a new logotype:
> http://github.com/eegg/happstack_redesign/raw/master/logo_1.png . Not sure
> how appropriate it is -- it vaguely reminds me of Harry Potter -- but I
> started off with the witchcraftyness of
> http://community.haskell.org/~hexpuem/logo_contest/haskell_5.png . I kept
> the blue that's predominant over the many happstack sources.
>
> Thoughts?
it have to be so complex or witchcrafty? A logo should be like how we
want users to see the product, and surely the last thing we need for
any Haskell stuff is to promote the idea that it's complex and
magical.
So, how about something simple, elegant, robust-looking?
Conrad.
Jeremy Shaw
David Bergman
Typed on an iPhone
James Fisher
Jeremy, thanks for taking the time for such an in-depth high-level description. Here's some miscellaneous things/metaphors/aphorisms I get from it (from a design point of view):
* The ideal solution for a small app doesn't work for a large one. The ideal solution for a large app doesn't work for a small one. Architectural change is thus inevitable.
* A butterfly is not a scaled-out caterpillar.
* The ideal solution for one type of app doesn't work for another type. You will, at some point, have to make your own design decisions.
* Happstack guides you through change.
* It councels rather than teaches.
* If Happstack was scaffolding for a building, it wouldn't constrain you to one type of building.
* Nothing in a framework should be 'built-in': it's there for you to *build in*.
* For any one subproblem (e.g. state storage), Happstack provides the containers for solutions, rather than just "the" solution -- though it offers those too
* In a vague way, Happstack is constancy through change.
* For all the diversity in the animal kingdom, we all run on DNA, cells, the same organs. Happstack is in some sense an origin of life -- from whence flowed diversity.
Some things that might represent Happstack:
An incubator of some kind.
Scaffolding.
A cocoon (protection through change...)
Or the whole caterpillar -> butterfly thing. Chrysalis. Metamorphosis.
Glue.
The root of the tree.
E pluribus unum.
What kind of level of 'fun' would you say Happstack's image should incorporate? Versus "enterprise solution" seriousness, I mean. Less fun than Harry Potter, I guess. Above I seem to have emphasized biological analogies; that's certainly a "fun" image to work with.
lol. That is very harry potter :)So, here is some unorganized, hand wavey, high conception ideas about happstack for you.The happstack project is focused on making it easy to build an server application which can grow to support a large number of users with out turning into a huge hack job.Although a majority of the effort is currently focused an delivering *web* applications, the framework is not limited to only web applications. For example, for april fools I released a telnet based happstack application.One principle of happstack is to not try to use a one-size fits all solution. If you look at big systems like eBay, amazon, facebook, etc, you find that they often even up with very customized, non-general solutions. For example, if you look at a system like facebook.com, they started with php+mysql, and still continue to use it. But they use mysql in a way that would make database designers cry. They use no transactions, etc, and all their tables just have two columns (key/value pairs). They don't use SQL joins, but instead simulate the joins in PHP. It's clear that their needs have outgrown the system, and they have been forced to hack weird stuff on top what they had, because you never have time to rewrite it from scratch.Trying to generalized facebook's system so that it could be used by amazon, ebay, etc, just wouldn't work. So, rather than attempt to make a general solution that is going to work for everyone, we want to make it as easy as possible for you to create the specialized solution that works for you. So, for example, happstack does provide a persistent data storage system, but you are not mandated to use it. If SQL *is* the best solution for your app, it is just as supported as happstack-state.Along similar lines, happstack has no *builtin* html templating solution. But we do make it easy to use, HSP, HStringTemplate, Text.(X)Html, and soon Hamlet. And, if you come up with your own homebrewed thing that is best for your app, then that should work just as well. This is important because different templating systems meet different goals. HSP is nice and rather powerful if you have Haskell programmers writing the html. But if you want an html designer to implement the pages, then you might want something more familiar and less powerful to give them.So, part of the happstack project is taking 3rd party technologies and integrating them nicely into the happstack eco-system.Of course, too much choice can be problematic. So, another part of the happstack project is trying to establish some reasonable 'best practices' for people to start their projects with. For example, we think that happstack-state is a great choice for many applications, and can simplify development and deployment, and can be easily modified to meet the specific needs of your site. So we want to foster the growth and adoption of that technology, and show people why they might want to consider it over SQL.In the most abstract sense, as you continue to develop and grow your application, you might actually end up with an application that does not use any code from the happstack project itself. As your site grows and adapts, you might find you have replaced all the happstack code with your own custom code. That is perhaps a bit unlikely, but conceptually, it is a fine idea. In that sense, happstack is not just the code, but the philosophy about how to design and build a site that is going to be able to adapt.So, adaptation is a pretty key concept I think. All businesses, websites, ideas, etc, that fail to adapt will die. If you are using a framework which makes it hard to adapt your site as your site grows, then you are going to be in a world of pain. What you need is a system that will allow you to adapt your site as easily as possible.In fact, I think the idea of 'web frameworks' has a tendency to put the emphasis as the framework being the king, and your application a humble servant of it. Which is clearly all backwards. Your web application is the only thing that matters, and if some of the functions and data structures in the happstack project make it easier to write your application, then great! But the libraries should always be the servant of your application.So, I am still working on refining this ramble down into something more meaningful...There is also a lot of stuff that is missing from this rant too :)I would *almost* consider happstack to be a community resource for people building application servers using Haskell. It would include discussions about solutions to various problems encountered while building web applications, recommended practices that will help keep your code adaptable, and a collection of libraries and tools which have been useful for addressing these problems, and which have been polished so they work well together.For example, one idea that has come up in the scalable application server realm is the idea of getting away from disk and using DRAM clouds.
Jeremy Shaw
> it have to be so complex or witchcrafty? A logo should be like how we
> want users to see the product, and surely the last thing we need for
> any Haskell stuff is to promote the idea that it's complex and
> magical.
>
> So, how about something simple, elegant, robust-looking?
simple. I am also not clear that simple is something that is valuable
in this case.
A knife is a pretty simple tool, though it can require considerable
skill to use it well. A really expensive damascus steel knife is still
just as simple -- though it may stay sharper longer, be better
weighted, etc. But it is still simple. Making it more complicated is
not going to make it appeal more to professional chefs.
But, happstack is more like a professional digital SLR than a knife. A
consumer point and shoot camera is typically pretty simple. You can
turn it on, press the shutter button to take a picture, and review the
images -- but that is about all. Very simple. By comparison a
professional dSLR is vastly more complicated -- multiple ways to do
everything. My camera has at least 5 different focus modes. I can
control if the flash goes on when the shutter first opens, or right
before it closes. There is a huge choice of lenses. There are dozens
of menus controlling all sorts of settings. But, these features are
desired by professionals because they make it easier or possible to
get the job done. So, the initial complexity of learning the tool is
worth it in the end.
Of course, there is also a lot of effort spent to make sure that the
camera is quick to use once you understand it. Lot's of focus on the
placement and number of buttons, etc. The cameras do also have fully
automatic modes. So, you can use it like a point and shoot -- just
turn it on and press the shutter button.
I think happstack is rather similar. If you start digging through
things like ServerMonad, the monad stack there is fairly complicated.
If you removed all the newtype wrappers, ServerPartT is basically:
type ServerPartT m a = ReaderT Request (ErrorT Response (WriterT
(SetAppend (Dual (Endo a))) (MaybeT m)) a
I don't think we can call that simple :)
But, it is useful complexity. The complexity of the ServerPartT
reduces the complexity of your program in other ways by providing
useful features and encapsulation and abstraction.
Like a dSLR, you don't have to use all the complexity. The happstack
hello world application:
main = simpleHTTP nullConf $ ok "hello, world!"
is certainly simple looking enough. And, hopefully, happstack doesn't
feel clumsy to use. So perhaps Happstack has simplicity in the sense
of, "scientific precision, neatness, and simplicity". Happstack
reduces a rather complex and messy domain to a just a few
abstractions...
So, I don't think simple is the best word to use -- but I think there
is a related concept. Something related to the idea of a sophisticated
tool where the parts fit together nicely and make life much easier for
the user ?
I am also a little bit dubious of describing happstack as robust. In a
typically happstack application, a majority of the code is application
specific, and doesn't use happstack at all. And, there is nothing
happstack can do to prevent you from making a horrible mess of your
code. So, saying that happstack is 'robust' seems to imply that
applications you build with it will be 'robust' -- though we can't
really offer that.
In a similar vein, Data.List is pretty close to being bug free. The
only possible bugs I know of all very subtle things such as functions
being slightly too lazy or too strict. And there is often debate about
whether that is even true. Yet despite the robustness of Data.List, it
is very easy to build all sorts of buggy stuff using it :)
We do, of course, want to give the correct impression that the
happstack code itself can be trusted. And that it can be used to build
robust applications.
At present, I have no issues with describing happstack as elegant :)
Though, I feel like we are missing something more critical in regards
to the appeal of happstack... haven't been able to my finger on what
it is yet.
- jeremy
James Fisher
James Fisher
Jeremy Shaw
On Apr 22, 2010, at 3:39 AM, James Fisher wrote:
> Cool. At least by throwing something at the group I've got people
> talking :)
>
> Jeremy, thanks for taking the time for such an in-depth high-level
> description. Here's some miscellaneous things/metaphors/aphorisms I
> get from it (from a design point of view):
>
> * The ideal solution for a small app doesn't work for a large one.
> The ideal solution for a large app doesn't work for a small one.
> Architectural change is thus inevitable.
because the needs of your application change over time. And the new
needs stress your application in different ways.
The ideal solution for amazon (large) is not the ideal solution for
facebook (large), because they have very different usage patterns.
Amazon has lots of products available for searching, facebook its
mostly focused on the most recently activity. At the same time, while
the specific implementation that facebook uses might not be good for
Amazon, there are general trends and concepts that are proving common
among large sites. For example, eBay, Amazon, Google, and Facebook do
not use nice transactional SQL databases with replication and 3nf
normalized tables. They have either done away with SQL altogether, or
they use it in very abusive ways.
One thing we do look at is how the lessons learned by large sites can
be applied when you are first building your app. For example, many
sites are finding that databases are too slow because of disk access,
and are trying to cache huge portions of their data in memcached to
avoid the disk penalty. happstack-state takes the opposite approach
-- rather than start with everything on disk, and then hope that some
magic tuning of cache parameters in going to get the right stuff in
RAM, we just start with everything in RAM. If you need to archive
stuff to disk, then your app can decide exactly what and when stuff
should be archived to disk. That means you don't have surprises
because your query that was working great during testing is suddenly
hitting the disk on the live server. The choice about what data is
unlikely to be needed quickly and can be stored on disk is clearly
very dependent on your data set, and so it seems natural that it
should be an explicit choice for the application designers to make
based on the empirical data they have collected.
It turns out that sticking everything in RAM has a number of benefits
even for small sites.
1. it simplifies deployment -- you don't have to have an apache
server, and SQL server, and mod_php, etc. You just install a single
binary and run it!
2. it simplifies development -- you don't have to marshal your
Haskell datatypes to and from SQL. You just work with nice Haskell
data types. And your queries are just haskell functions. You don't
have to worry about SQL string injections or any of that silliness. In
an application I am working on now, we make extensive use of algebraic
data types and graphs. I can't even imagine having tried to develop it
in SQL.
So, if you are working by yourself, or on a small team, it is actually
a great thing. Given your very limited time, you can focus on the
important stuff instead of worrying about mysql installation issues,
etc. And, hopefully, as your site grows, you won't find yourself
fighting against a system that can't grow that way.
Another popular trend (at least for a while) was object relational
mapping (ORM). People saw the advantages of working with native
language data types, instead of thinking in SQL. So they tried to hide
the SQL-ness via ORM. But, in practice, this did not work so well.
Trying to map objects onto SQL caused really bizarre access patterns
that the databases could not keep up with.
happstack-state offers the appeal of ORM, except with out having to
try to map datatypes to some foreign system. Instead we use a native
write-ahead logging system that can provide the ACID properties of a
normal database, but is optimized for the purpose of storing happstack-
state transactions. (During normal operation, we only write to the
disk, and do it in a sequential manner, allowing us to achieve very
high disk throughput. )
> * A butterfly is not a scaled-out caterpillar.
> * The ideal solution for one type of app doesn't work for another
> type. You will, at some point, have to make your own design
> decisions.
> * Happstack guides you through change.
> * It councels rather than teaches.
> * If Happstack was scaffolding for a building, it wouldn't constrain
> you to one type of building.
> * Nothing in a framework should be 'built-in': it's there for you to
> *build in*.
everything is optional/replaceable. We do provide a lot of built-in
functionality in the happstack-* libraries, and we also 'build-in'
support for libraries we did not write ourselves (such as support for
various templating libraries). But we try not to demand that you use
any of it. So, it is more that it is highly modular, pluggable, and
extendable?
> * For any one subproblem (e.g. state storage), Happstack provides
> the containers for solutions, rather than just "the" solution --
> though it offers those too
> * In a vague way, Happstack is constancy through change.
> * For all the diversity in the animal kingdom, we all run on DNA,
> cells, the same organs. Happstack is in some sense an origin of
> life -- from whence flowed diversity.
> Some things that might represent Happstack:
>
> An incubator of some kind.
> Scaffolding.
> A cocoon (protection through change...)
> Or the whole caterpillar -> butterfly thing. Chrysalis.
> Metamorphosis.
> Glue.
> The root of the tree.
> E pluribus unum.
>
> What kind of level of 'fun' would you say Happstack's image should
> incorporate? Versus "enterprise solution" seriousness, I mean.
> Less fun than Harry Potter, I guess. Above I seem to have
> emphasized biological analogies; that's certainly a "fun" image to
> work with.
cool and powerful, even if they aren't really clear on how it works
yet. Like if you found a UFO crash site, and you found some cool alien
technology that was really different from any device you had seen
before, but was obviously much better too, and you think "man, this
thing is awesome, I gotta learn how to use it." :)
I'll see what else I can come up with..
- jeremy
Jeremy Shaw
tphyahoo
FWIW, I actually like the harry potter logo more than the tree (modulo
a bit less fadiness), though I don't think either one is ready for
prime time.
For other ideas
-- how about something that incorporates the idea of a stack of
technology.
-- Or, a knapsack -- all the stuff you need, in a bag, ready to go.
(Cause happstack sounds like "knapsack".)
t.
Matthew Elder
Need somewhere to put your code? http://patch-tag.com
Want to build a webapp? http://happstack.com
Andrey Chudnov
> > tried that. We just use whatever haddock spits out.
>
> I had wondered that. Can't be too hard to just inject a CSS reference
> though. (Though I notice it spits out the most god-awful tables... maybe
> that's something I could work on sometime.)
snapframework.com/docs/api/snap-core)
@All: I think Snap framework is worth having a look at
(snapframework.com), though right now it's only a web-server and a
template system (both look pretty darn good). They claim to have
beaten the Happstack web server performance (http://snapframework.com/
benchmarks). Also, they've got excellent documentation.
Gracjan Polak
On 24 Maj, 23:57, Andrey Chudnov <achud...@gmail.com> wrote:
> @All: I think Snap framework is worth having a look at
> (snapframework.com), though right now it's only a web-server and a
> template system (both look pretty darn good). They claim to have
> beaten the Happstack web server performance (http://snapframework.com/
> benchmarks). Also, they've got excellent documentation.
I've found it quite interesting on the benchmark page that Happstack
fared so well in comparison to Apache/PHP!
How hard would it be to implement pipelining?
How hard would it be to support libevent?
--
Gracjan
Jeremy Shaw
On 24 Maj, 23:57, Andrey Chudnov <achud...@gmail.com> wrote:@All: I think Snap framework is worth having a look at(snapframework.com), though right now it's only a web-server and atemplate system (both look pretty darn good). They claim to havebeaten the Happstack web server performance (http://snapframework.com/benchmarks). Also, they've got excellent documentation.
I've found it quite interesting on the benchmark page that Happstack
fared so well in comparison to Apache/PHP!
How hard would it be to implement pipelining?
How hard would it be to support libevent?
Gracjan Polak
On 25 Maj, 23:33, Jeremy Shaw <jer...@n-heptane.com> wrote:
> On May 25, 2010, at 3:36 PM, Gracjan Polak wrote:
>
> > I've found it quite interesting on the benchmark page that Happstack
> > fared so well in comparison to Apache/PHP!
>
> yay!
>
> > How hard would it be to implement pipelining?
>
> Not sure it is really worth it. Happstack does support multiple
> request/responses over the same persistent connection. So we are not
> paying the overhead of setting up a new connection for each request.
> Pipeline just allows you to send all the requests at the beginning,
> instead of interleaving the request/response pattern. But it doesn't
> seem like that would be a very big win.
Ok, I read about pipelining and understand why it is not worth the
trouble.
Still the other day I got some responses with Connection: close when I
did not expect that. What can possibly be the reason?
--
Gracjan
Gregory Collins
> How hard would it be to implement pipelining?
>
> Not sure it is really worth it. Happstack does support multiple
> request/responses over the same persistent connection. So we are not
> paying the overhead of setting up a new connection for each
> request. Pipeline just allows you to send all the requests at the
> beginning, instead of interleaving the request/response pattern. But
> it doesn't seem like that would be a very big win.
Re: pipelining, if you support keepalive on the server side you
shouldn't have to do anything special to handle pipelined requests. The
performance issue we were seeing w/ happstack-server & sendfile is that
it doesn't seem to support keepalive for sendfile requests, at least in
our testing.
> On my machine, with a single core, and a slightly tweaked file serve
> test, I got essentially identical results for the image serving
> test. This makes sense, as most of the time is spent in sendfile
> anyway. I believe most of the speed differences in that test are due
> to running snap on 4-cores vs 1-core for happstack.
Yes, in theory fileserve performance *should* be identical (modulo the
speed of http parsing), we use the same sendfile library :)
BTW from looking at the sendfile library, it looks like it could be a
bit faster, at least on posix -- Word64 might be better than "Integer"
for offset and bytecount, doing an fstat() on posix probably a bit
faster than hFileSize, etc.
Wonder how much difference those changes would actually make -- GMP is
pretty slow.
> How hard would it be to support libevent?
>
> Both easy and hard. My experimental port of happstack-server to wai
> shows that it is not that hard to retarget happstack-server to a new
> backend.
>
> The 'hard part' is writing the backend itself I suspect. In theory, I
> would like to just leverage an existing (iteratee) backend, such as
> hyena. However, I've been waiting to do that for a year.. so maybe it
> would just be better to bite the bullet and add something custom for
> now.
It shouldn't be too much work to make happstack apps run on top of Snap
if anyone is interested.
G
--
Gregory Collins <gr...@gregorycollins.net>
Jeremy Shaw
Jeremy Shaw
On May 25, 2010, at 4:55 PM, Gregory Collins wrote:
> Jeremy Shaw <jer...@n-heptane.com> writes:
>
>> How hard would it be to implement pipelining?
>>
>> Not sure it is really worth it. Happstack does support multiple
>> request/responses over the same persistent connection. So we are not
>> paying the overhead of setting up a new connection for each
>> request. Pipeline just allows you to send all the requests at the
>> beginning, instead of interleaving the request/response pattern. But
>> it doesn't seem like that would be a very big win.
>
> Re: pipelining, if you support keepalive on the server side you
> shouldn't have to do anything special to handle pipelined requests.
> The
> performance issue we were seeing w/ happstack-server & sendfile is
> that
> it doesn't seem to support keepalive for sendfile requests, at least
> in
> our testing.
Right. We don't do anything special.
Turns out there was a bug where we were setting the close connection
header for sendfile for no good reason. That is fixed in darcs now.
>> On my machine, with a single core, and a slightly tweaked file serve
>> test, I got essentially identical results for the image serving
>> test. This makes sense, as most of the time is spent in sendfile
>> anyway. I believe most of the speed differences in that test are due
>> to running snap on 4-cores vs 1-core for happstack.
>
> Yes, in theory fileserve performance *should* be identical (modulo the
> speed of http parsing), we use the same sendfile library :)
Right. Though we might have some extra overhead in our fileserve
library.. such as the giant list of mime-types.
> BTW from looking at the sendfile library, it looks like it could be a
> bit faster, at least on posix -- Word64 might be better than "Integer"
> for offset and bytecount, doing an fstat() on posix probably a bit
> faster than hFileSize, etc.
>
> Wonder how much difference those changes would actually make -- GMP is
> pretty slow.
Dunno. But I have commit access if you send a patch. (And maybe some
test results to show it makes a difference?)
>
>> How hard would it be to support libevent?
>>
>> Both easy and hard. My experimental port of happstack-server to wai
>> shows that it is not that hard to retarget happstack-server to a new
>> backend.
>>
>> The 'hard part' is writing the backend itself I suspect. In theory, I
>> would like to just leverage an existing (iteratee) backend, such as
>> hyena. However, I've been waiting to do that for a year.. so maybe it
>> would just be better to bite the bullet and add something custom for
>> now.
>
> It shouldn't be too much work to make happstack apps run on top of
> Snap
> if anyone is interested.
It is certainly tempting. I have been hoping to port to hyena for a
long time, but that project seems a bit stalled perhaps?
The unpredictable nature of lazy I/O is not a good thing, so I think
iteratees are ultimately the way to go for happstack.
There are two approaches we can take:
1. just rip out the current backend and use a different one (what I
did with the happstack-wai port)
This method has a few advantages:
1. less code in happstack to maintain
2. more people using the backend == more bug fixes and
performance improvements
2. extend the current backend to also work with iteratees. For
example, extend the Response type so that in addition to the current
Response constructor that uses lazy I/O it also has a Response that
uses iteratees.
The advantage of the second method is that it results is less code
breakage, because it is just adding new stuff. Then we can phase out
the old stuff.
But, I think the breakage is maybe not that bad anyway. Most of the
code that is generating Responses goes through a toResponse call
anyway. If we just modify all the default ToMessages instances, then
most code won't require much in the way of changes. And people can
just use enumFromLazyByteString or something to convert their own
instances.
Obviously, they won't get the full benefits of iteratees that way, but
if they are just looking to migrate their app, it ought to be pretty
painless.
The biggest 'issue' with a port to the snap backend right now is that
the part happstack wants to use is all mixed up with the rest of the
code. For example, Snap.Types has the Request and Response types,
which happstack would use, but also the Snap monad. And snap-core
contains the types we want, but also things like file serving
utilities. We can, of course, ignore the things we don't want.. but
when those things also add even more cabal dependencies, that is
annoying. Happstack already has too many dependencies.
- jeremy
Antoine Latter
This has bit me in past projects, wher I've had wget hanging on me at the console because having happstack send a content-length header would have destroyed performance.
Maybe wget was doing something funny, though.
On May 25, 2010 5:39 PM, "Jeremy Shaw" <jer...@n-heptane.com> wrote:
On May 25, 2010, at 4:50 PM, Gracjan Polak wrote:
>
>
> On 25 Maj, 23:33, Jeremy Shaw <jer...@n-he...
If you were serving files, it is because I just fixed a bug in the sendfile code. If it was something else.. then I would need more details.We use keep-alive provided when these conditions hold:continueHTTP rq res = (isHTTP1_0 rq && checkHeaderBS connectionC keepaliveC rq) ||(isHTTP1_1 rq && not (checkHeaderBS connectionC closeC rq)) && rsfContentLength (rsFlags res)Which is basically:HTTP 1.0, but they requested keep-aliveHTTP 1.1, they *didn't* request a close, and the content we are sending includes a content-length.- jeremy
--
You received this message because you are subscribed to the Google Groups "HAppS" group.
To po...
Gregory Collins
> The biggest 'issue' with a port to the snap backend right now is that
> the part happstack wants to use is all mixed up with the rest of the
> code. For example, Snap.Types has the Request and Response types,
> which happstack would use, but also the Snap monad. And snap-core
> contains the types we want, but also things like file serving
> utilities. We can, of course, ignore the things we don't want.. but
> when those things also add even more cabal dependencies, that is
> annoying. Happstack already has too many dependencies.
I was thinking instead of a package "snapstack", which exports a
function:
snapstack :: ServerPartT IO Response -> Snap ()
and also an
httpServe :: ... -> ServerPartT IO Response -> ... -> IO ()
Basically: convert the request/response types and run the happstack
monad. The conversion would be a little bit of fixed overhead.
Gregory Collins
> We use keep-alive provided when these conditions hold:
>
> continueHTTP rq res = (isHTTP1_0 rq && checkHeaderBS connectionC keepaliveC rq) ||
> (isHTTP1_1 rq && not (checkHeaderBS connectionC closeC rq)) && rsfContentLength (rsFlags res)
>
> Which is basically:
>
> HTTP 1.0, but they requested keep-alive
>
> HTTP 1.1, they *didn't* request a close, and the content we are
> sending includes a content-length.
Why don't you do chunked transfer encoding on http/1.1?
Jeremy Shaw
But, if we are converting the existing happstack Response type into a
snap Response, then we wouldn't be able to use iteratees?
Also, it just complicates the code even more than it already is. Adds
even more monads!
What is the advantage of doing things that way over just using the
snap Request/Response types natively?
It would be useful if we simply want to use some existing happstack
code in a snap application. But the goal is to 'permanently' improve
the the happstack server backend and get rid of the existing lazy I/O
code altogether..
- jeremy
Jeremy Shaw
I assume you are asking why we don't use chunked transfer encoding
when we don't know the length so that we can support keep-alive even
in that case?
I think it's because all the people interested in writing low-level
http server code are working on their own servers instead of
contributing to happstack :p
It's not too late though, you can still submit a patch ;)
- jeremy
Gregory Collins
> But, if we are converting the existing happstack Response type into a
> snap Response, then we wouldn't be able to use iteratees?
Yeah it'd strictly be a compatibility layer.
> Also, it just complicates the code even more than it already is. Adds
> even more monads!
>
> What is the advantage of doing things that way over just using the
> snap Request/Response types natively?
You get to run existing happstack code without modification, that's it.
> It would be useful if we simply want to use some existing happstack
> code in a snap application. But the goal is to 'permanently' improve
> the the happstack server backend and get rid of the existing lazy I/O
> code altogether..
If you would want to move ServerPartT closer to Snap then you may as
well just *use* Snap, the monad is almost identical after all.
Gregory Collins
> I assume you are asking why we don't use chunked transfer encoding when we
> don't know the length so that we can support keep-alive even in that case?
>
> I think it's because all the people interested in writing low-level http server
> code are working on their own servers instead of contributing to happstack :p
>
> It's not too late though, you can still submit a patch ;)
Touche! :)
Jeremy Shaw
It would be useful if we simply want to use some existing happstackcode in a snap application. But the goal is to 'permanently' improvethe the happstack server backend and get rid of the existing lazy I/Ocode altogether..
If you would want to move ServerPartT closer to Snap then you may as
well just *use* Snap, the monad is almost identical after all.
MightyByte
> As for using the snap-backend: The aim is not to change ServerPartT monad,
> but to change the happstack Request type so that the rqBody is an iteratee
> instead of a lazy bytestring. (and some similar changes to the Request
> type). For that I think we need a library that exposes just four things:
> 1. Response type
> 2. Request type
> 3. Config type
> 4. run :: Config -> (Request -> IO Response) -> IO ()
> I can get all those things out of the snap-core + snap-server libraries.
> But, I am concerned that as snap grows, I will start needing a bunch of
> extra dependencies that have nothing to do with those 4 features.. :-/
The bulk of new development for Snap will happen outside of snap-core
and snap-server. We're sensitive to dependency creep and intend to
keep -core and -server is simple as possible.
Johan Tibell
It is certainly tempting. I have been hoping to port to hyena for a long time, but that project seems a bit stalled perhaps?
Gregory Collins
> I can get all those things out of the snap-core + snap-server
> libraries. But, I am concerned that as snap grows, I will start
> needing a bunch of extra dependencies that have nothing to do with
> those 4 features.. :-/
The snap-core library is going to stay roughly where it is going forward
-- probably any additional utilities to go in there will be in the
"doesn't introduce additional dependencies" category. We're planning on
putting Snap's more "frameworky" stuff in other packages.
Don Stewart
This was a huge lesson from xmonad: keep the dependencies very light for
basic functionality, or the distros -- and thus users and end-user
facing apps -- can't keep up.
-- Don
Gracjan Polak
On 26 Maj, 21:54, Johan Tibell <johan.tib...@gmail.com> wrote:
> Unfortunately I haven't had any time to work on Hyena for a long time. I've
> been yak shaving, trying to improve the GHC I/O manager so that all Haskell
> web servers can benefit from better performance (if you want to help please,
> please try out the code on github [1] and report bugs).
I find your work on GHC I/O really interesting and important. It seems
to be a bit above my level of Haskell expertise, though. Anyway if you
need assistance with for example Windows port or testing I'd glad to
help.
--
Gracjan
Johan Tibell
The event lib offers a subset of the interface in GHC.Conc. GHC.Conc will be implemented in terms of this smaller interface once the new I/O manager has been merged into base. You can play with this interface today. It's defined in
http://github.com/tibbe/event/blob/master/src/System/Event/Thread.hs
This interface can in turn be used to implement the network-bytestring interface and we've already done so:
http://github.com/tibbe/event/blob/master/benchmarks/EventSocket.hs
Using the function in EventSocket it's possible to build a server in typical Haskell style, using forkIO to handle each request. Bryan wrote a small HTTP server using this interface
http://github.com/tibbe/event/blob/master/benchmarks/StaticHttp.hs
Running this server (it can be built using the Makefile) could help us find bugs on different platforms. For Windows support we still need to write a select() backend. This should be pretty easy as it can be modelled after the poll backend:
http://github.com/tibbe/event/blob/master/src/System/Event/Poll.hsc
Gregory Collins
> Running this server (it can be built using the Makefile) could help us
> find bugs on different platforms. For Windows support we still need to
> write a select() backend. This should be pretty easy as it can be
> modelled after the poll backend:
For Windows we really should be using I/O completion ports. Huge pain
in the butt though!
Johan Tibell
Johan Tibell <johan....@gmail.com> writes:For Windows we really should be using I/O completion ports. Huge pain
> Running this server (it can be built using the Makefile) could help us
> find bugs on different platforms. For Windows support we still need to
> write a select() backend. This should be pretty easy as it can be
> modelled after the poll backend:
in the butt though!
Johan
Jeremy Shaw
Using the function in EventSocket it's possible to build a server in typical Haskell style, using forkIO to handle each request. Bryan wrote a small HTTP server using this interface
http://github.com/tibbe/event/blob/master/benchmarks/StaticHttp.hs
Gregory Collins
You won't see much a difference unless you push it past 1024 open
connections -- event-based server will keep processing requests,
GHC-IO-manager-based-server will start refusing requests.
Jeremy Shaw
When I tried that I got,
~/n-heptane/projects/haskell/event/benchmarks $ ./static-http
static-http: accept: resource exhausted (Too many open files)
:-/
- jeremy
Matthew Elder
--
You received this message because you are subscribed to the Google Groups "HAppS" group.
To post to this group, send email to ha...@googlegroups.com.
To unsubscribe from this group, send email to happs+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/happs?hl=en.
--
Need somewhere to put your code? http://patch-tag.com
Want to build a webapp? http://happstack.com
Matthew Elder
Matthew Elder
ulimit -n