Am 29.04.2012 06:18, schrieb Martin Nowak:
Very nice to see that someone took the async/Fiber idea that far.
Some observations:
- Wouldn't wrapping code in "void main()" instead of "static this()"
make better front page examples.
The static this() pattern is mainly there to appeal to users of similar
systems in script languages, where you don't have a main function at all
and just happily hack away. For larger projects it doesn't make a
difference but for small projects it can actually be quite convenient.
Maybe it would be a good idea to place a prominent example of how it's
possible to define your own main() to gain additional control.
- It would be interesting to know what made you write your own
Stream/JSON implementations.
Stream has a number of additional functions or parameters such as
leastSize() that are required or extremely convenient in this context.
Also to avoid dragging in something like std.stream.File which has
sychronous behavior and would block the event loop without anyone
noticing it until the resulting bad performance under high-load
conditions shows.
The reasons for writing an own Json implementation is that the interface
of std.json is.. well.. nice if you write something in C. The
implementation in vibe tries to let Json seem like a natural dynamic
type of the language as far as it makes sense. The std.json parser can
also only parse string buffers and I wanted to have something that can
easily be used to work efficiently on a stream. Support for pretty
printing was another reason (would of course also easy to add on top of
std.json).
- I think there is some interest in having the HTTP handling and the
templates in a separate library.
My considerations are that if you don't use the HTTP/... parts, it will
neither occupy space in your app, nor will it drag in any additional
dependencies. That separate library would basically be vibe.core and
vibe.stream vs. the rest of modules. And dependency-wise they are
already separate (core and stream have no outside dependencies to the
library).
If on the other hand you wanted to use the HTTP/... stuff together with
other libraries in a blocking, non-fiber environment, it would also just
work - all operations are also working and blocking outside of the event
loop.
