updateRoot: Weirdness

> I don't think that  everyone is interested in being an expert at
> configuring wierdo linux technologies. I myself have no intention of
> ever having to write apache rewrite rules. If I ever have to then I
> figure something is wrong.
>
> Why do I think this way you might ask. It is simple, I am a mac user!
>
> Not that I cant do the "hard" stuff, I used to program my PC's in C back
> in '85 and mc code before that.
>
> The fact is that I don't want to.
>
> I don't know why everything is so hard. When you collect your images
> together, when you edit your images where are they? On disk, so where
> should you be able to serve them from by default. Yes thats right ON DISK.
>
> If you are fine tuning your site, editing you images what don't you want
> the browser to do? Thats right you don't want it to cache the images!
> Can seaside do this out of the box no it can't! Never mind accessing
> databases, seaside cant even serve files.
>
> Moving the file in-image is an optimization, and its quite nice for
> distributing a pre-configured image without lots of supporting files,
> but its not the simplest thing to configure or use. Throwing your files
> into a directory or a directory hierarchy is. And seaside cant handle
> that, despite, as I was told recently trying to embody the 80-20 rule,
> that is supporting the majority of what users want to achieve.
>
> So in terms of lowering the bar for newbies some things are basically
> obvious, but seaside has acquired an "elitist" approach. It appears that
> some things (like serving files) are beneath it, and "best left to
> apache". So it turns out that due to this elitism, seaside cant even do
> the basics out of the box. The purist mentality doesnt allow for the
> "seaside does what it does, and does it well" to be poluted by
> compromise positions which would make things more flexible and therefore
> perhaps more broadly usable. Serving files is but one example, using
> cookies for day to day site things is another, this facility almost
> disappeared from 2.8a unnoticed.
>
> Now I would like to be able to rectify this situation, but I have a
> distinct disadvantage, I don't write perfect code, I throw something
> together which does the job, I need others with different skills to
> refine and hone the result to perfection.
>
> So as it happens I have on numerous occasions attempted to submit code
> which addresses some of these (imho) shortfalls. And time and time again
> the purists reject much of what I have offered out of hand. For various
> reasons, some of them good reasons. Nevertheless I got tired of the
> continuous negative attitude that comes out in this "protecting the
> purity" of seaside.
>
> This has resulted in me making a complete ass of myself by loosing my
> rag (fortunately in private) at the maintainers. I have apologized, and
> if you have noticed that the seaside repository is now read only, thats
> probably all my fault that I pissed off the maintainers and I apologize
> to them and also to the community for that.
>
> But lets examine this a little bit, one example.
>
> Seaside configuration attributes are organized into groups. So the
> function "tell me if this application has the configuration group named
> x" (so I can add a dispatcher plugin to it). This function is an
> accessor into private information encapsulated within the seaside kernel
> so to speak. So in order to make this useful as a feature, whose
> responsibility would it be to provide an accessor? I would say the
> package that implements the feature should expose enough of that feature
> in a public api so as to be useful to users who want to use it. So I
> suggest #hasGroupNamed: accessor  to match its existing counterpart
> #hasAttributeNamed:
>
> The objection I am given is: "This is dangerous". Why? Because it has no
> users within the seaside core package, and having no users it is fragile
> and might break or be removed without anyone noticing. Well hang on,
> isnt that obvious! It isnt in the base package 'yet' so of course it
> hasn't got any users, its whole purpose is to be a public API so that
> clients and extensions to the base package can use it. Its reason for
> being that is to support users external to the core, not internal to the
> core, the internals probably dont need it since they can access the
> value directly etc. So somehow we have this statement of law which says
> "No public api shall be exposed which is not used inside the grey-box of
> the core, which incidentally doesnt need a public api anyway".
>
> So what if it does break? Well if it doesnt have any users inside the
> core seaside package, then who cares. Its not dangerous at all, if it
> breaks its not going to ruin anyones day. Ok so I, with three users of
> this api might miss it and flag if it becomes broken. But dangerous it
> is NOT.
>
> This really got my goat I am afraid, I attempted to put this accessor
> into the seaside repository 6 times or more. And it still hasnt made it
> past the idealistic police. Now I am not writing code or uploading to
> monticello for my health. Can you wonder why I got a little peeved.
>
> So if you are wondering why seaside doesnt make progress in attracting
> broader appeal, one possible answer is that the maintainers have a very
> narrow and purist perspective. Which is worthwhile, and serves a purpose
> to make seaside better in a certain focussed way, just not in the way
> that will broaden seaside's appeal (imnsho).
>
> So lets turn to the question at hand, serving files. What would it take
> to add this to seaside.
>
> 1 Method thats all! Where is it? Not there? Why not? because I guess
> serving files must be in the 20 of the 80/20 mentioned earlier. Who
> decides this? Well someone who likes configuring apache I guess.
>
> So in a three method varient a) subclass FileLibrary add an instVar
> fileNames and load it up with any resources you want to serve in-image
> as defaults which the files can then override.
>
> the methods:
>
> WAFileBasedLibrary-initialize
>
>     fileNames := self libraryDirectory fileNames
>
> WAFileBasedLibrary-libraryDirectory
>
> ^FileDirectory default directoryNamed: 'resources'
>
> WAFileBasedLibrary-documentAt: aFilename ifAbsent: aBlock
>    
>     | doc |
>  
>     (fileNames includes: aFilename)
>         ifFalse: [ ^ super documentAt: aFilename ifAbsent: aBlock ].
>  
>     doc := (WACachedDocument
>             fileName:  (self libraryDirectory pathName, FileDirectory
> slash , aFilename)) asMIMEDocument.
>
>      ^  WAResponse
>             document: doc
>             mimeType: doc mimeType
>
> Bingo, now that wasn't hard was it, throw any files you want to serve
> into 'resources' directory and you are away.
>
> best regards
>
> Keith
>
>
> _______________________________________________
> Seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> Keith Hodges wrote:
> > I don't think that  everyone is interested in being an expert at
> > configuring wierdo linux technologies. I myself have no intention of
> > ever having to write apache rewrite rules. If I ever have to then I
> > figure something is wrong.
> Of course.  I'm sure your rant isn't directed at me but I'd like to
> point out that often times these weirdo technologies are the best
> solutions for the problem.  You're right that not /everyone/  is
> interested in them.
>
> Anyway, my reasoning was kind of linear...you should store static
> content on the file system because ultimately you'll be using apache to
> serve it anyway.  Yours was different...you should store static content
> on the file system because the tools you use to manage this content are
> file-based.  In either case we agree on result.
>
> What we need is a solution that makes it easy for beginners to serve
> static content through Squeak (from the image and/or file system,
> doesn't matter) and to switch to a front-end web server if/when the need
> presents itself.   FWIW I also tried to get a solution to this problem
> into the base distro.  WAKom class>>startOn:servingFilesFrom: configured
> Comanche, not Seaside, to serve files from your selected directory but
> it was dropped...twice.

> Based on discussions with Lukas I believe that
> he is determined to see the in-image file library concept adopted by
> beginners but I think it has many pitfalls (of which you cited a few).
> Maybe this will be the beginning of a larger discussion on this
> topic?...now that several of us are clearly interested in improving the
> situation.
>
> BTW, serving static content is my #1 FAQ in personal e-mails from new
> Seaside developers.  URL mapping is #2.
>
> David
>
> _______________________________________________
> Seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>

> 2007/7/19, sig <[hidden email]>:
> > As people says: don't put all of eggs in one basket.
> >
> > Serving all content from single image is nice, but its not always achievable.
> >
> > As web server, Seaside must serve as front-end for delivering content
> > on the web, but not dictate, the original source of content.
>
> Seaside is not a webserver and not a database layer. It is a web
> application development framework. Webservers live Apache for lighttpd
> are preferable for serving static files because this is the job they
> are really good at and optimized for. They are written in C they use
> epoll/sendfile and multiple processors and caching and what not. It is
> a simple one time investment that takes off load of your
> Squeak/Seaside image and gives it more time and resources to do what
> it is good and optimized for: dynamic content. That doesn't mean there
> is no place for a simple solution for simple problems. But at the end
> of the day for any serious application you will need a standalone
> webserver.
>

> Philippe
>
> > Is there something wrong with this concept?
> > _______________________________________________
> > Seaside mailing list
> > [hidden email]
> > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
> >
> _______________________________________________
> Seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>

> On 19/07/07, Philippe Marschall <[hidden email]> wrote:
>> 2007/7/19, sig <[hidden email]>:
>> > As people says: don't put all of eggs in one basket.
>> >
>> > Serving all content from single image is nice, but its not always
>> achievable.
>> >
>> > As web server, Seaside must serve as front-end for delivering content
>> > on the web, but not dictate, the original source of content.
>>
>> Seaside is not a webserver and not a database layer. It is a web
>> application development framework. Webservers live Apache for lighttpd
>> are preferable for serving static files because this is the job they
>> are really good at and optimized for. They are written in C they use
>> epoll/sendfile and multiple processors and caching and what not. It is
>> a simple one time investment that takes off load of your
>> Squeak/Seaside image and gives it more time and resources to do what
>> it is good and optimized for: dynamic content. That doesn't mean there
>> is no place for a simple solution for simple problems. But at the end
>> of the day for any serious application you will need a standalone
>> webserver.
>>
>
> Hey, lets look to the roots: Seaside serving http requests. And i can
> assure you, that for 99% of the users in the world, thing which
> serving http requests called web-server.
> You may call it web application development framework or anything you
> want, but this will not makes any difference unless you stop handling
> http requests.
> Its a layer, which delivers content to browsers using standard
> protocol and from this point of view, it must be flexible enough to be
> able to deliver any content which developer wants to.
>
> And you saying 'standalone web server'.. It looks like you insist that
> seaside in 90% cases in not complete solution for _BASIC_ web
> solutions?
> Why it must force developer to use third party tools to be complete?
> Its better to be slow, as hog but be COMPLETE rather than flexible,
> complex, but incomplete...
>
>
>> Philippe
>>
>> > Is there something wrong with this concept?

> Notice that now having some real Seaside tests in VW is really boosting
> understanding how things work excellent !
>
> @+Maarten,
>
>
>      > Message du 19/07/07 11:16
>      > De : "Janko Mivšek"
>      > A : "Seaside - general discussion"
>      > Copie à :
>      > Objet : [Seaside] Swazoo web server (was updateRoot: Weirdness)
>      >
>      > Dear Seasiders,
>      >
>      > Let me remind you that there is a web server in Smalltalk named
>     Swazoo
>      > (http://www.swazoo.org) and that it was recently ported to Squeak
>     too.
>      > All you need is to connect it to a Seaside. This can be done easily
>      > because it is already done by Michel Bany on VW Seaside.
>      >
>      > That way you get a nicely packed web app server, with easy, out
>     of the
>      > box installation. And from experience so far I can say that
>     Swazoo is
>      > capable to serve small to medium sized public web sites and all
>      > intranets. So, only for really big websites you need to start
>     thinking
>      > to go Apache or lighthttp way ...
>      >
>      > Best regards
>      > Janko
>      > Maintainer of Swazoo
>      >
>      >
>      > sig wrote:
>      > > On 19/07/07, Philippe Marschall wrote:
>      > >> 2007/7/19, sig :
>      > >> > As people says: don't put all of eggs in one basket.
>      > >> >
>      > >> > Serving all content from single image is nice, but its not
>     always
>      > >> achievable.
>      > >> >
>      > >> > As web server, Seaside must serve as front-end for
>     delivering content
>      > >> > on the web, but not dictate, the original source of content.
>      > >>
>      > >> Seaside is not a webserver and not a database layer. It is a web
>      > >> application development framework. Webservers live Apache for
>     lighttpd
>      > >> are preferable for serving static files because this is the
>     job they
>      > >> are really good at and optimized for. They are written in C
>     they use
>      > >> epoll/sendfile and multiple processors and caching and what
>     not. It is
>      > >> a simple one time investment that takes off load of your
>      > >> Squeak/Seaside image and gives it more time and resources to
>     do what
>      > >> it is good and optimized for: dynamic content. That doesn't
>     mean there
>      > >> is no place for a simple solution for simple problems. But at
>     the end
>      > >> of the day for any serious application you will need a standalone
>      > >> webserver.
>      > >>
>      > >
>      > > Hey, lets look to the roots: Seaside serving http requests. And
>     i can
>      > > assure you, that for 99% of the users in the world, thing which
>      > > serving http requests called web-server.
>      > > You may call it web application development framework or
>     anything you
>      > > want, but this will not makes any difference unless you stop
>     handling
>      > > http requests.
>      > > Its a layer, which delivers content to browsers using standard
>      > > protocol and from this point of view, it must be flexible
>     enough to be
>      > > able to deliver any content which developer wants to.
>      > >
>      > > And you saying 'standalone web server'.. It looks like you
>     insist that
>      > > seaside in 90% cases in not complete solution for _BASIC_ web
>      > > solutions?
>      > > Why it must force developer to use third party tools to be
>     complete?
>      > > Its better to be slow, as hog but be COMPLETE rather than flexible,
>      > > complex, but incomplete...
>      > >
>      > >
>      > >> Philippe
>      > >>
>      > >> > Is there something wrong with this concept?

> 2007/7/19, sig <[hidden email]>:
>> As people says: don't put all of eggs in one basket.
>>
>> Serving all content from single image is nice, but its not always achievable.
>>
>> As web server, Seaside must serve as front-end for delivering content
>> on the web, but not dictate, the original source of content.
>
> Seaside is not a webserver and not a database layer. It is a web
> application development framework. Webservers live Apache for lighttpd
> are preferable for serving static files because this is the job they
> are really good at and optimized for. They are written in C they use
> epoll/sendfile and multiple processors and caching and what not. It is
> a simple one time investment that takes off load of your
> Squeak/Seaside image and gives it more time and resources to do what
> it is good and optimized for: dynamic content. That doesn't mean there
> is no place for a simple solution for simple problems. But at the end
> of the day for any serious application you will need a standalone
> webserver.
>
> Philippe
>
>> Is there something wrong with this concept?
>> _______________________________________________
>> Seaside mailing list
>> [hidden email]
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>
> _______________________________________________
> Seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> Hi Stef,
>
>> I think that the audience of david is different than yours and
>> serving large flash or photoshop image by newbie that do not
>> know well apache is something that we cannot push on them. We are
>> writing a book for beginners and we should take that
>> into account. Not everybody is an apache expert. I'm not for example.
>> Still it may make sense to me to be able to serve large files that
>> are not in the image.
>
> certainly it makes sense, but Seaside is not about serving static
> files. Kom itself doesn't do that any better. So why using a
> complicated solution (that has no use in practice) when a simple one
> (that has no use either, but is simple and works well for prototyping)
> would do as well?
>
>> So did I understand correctly that we will have to create our own
>> distribution because you will not add the method I asked
>> david to do to hide some ugly parts of his setup to serve file?
>
> I don't mind to add a single method, but we try to keep Seaside as
> clean and independent of the underlying architecture as possible. The
> code used to serve files does not follow the idea of Seaside (and
> Smalltalk in general) and does not work together with anything else
> than WAKom on Squeak (there are two other ones available in Squeak,
> VisualWorks/Dolphin uses a different Web server).
>
> Cheers,
> Lukas
>
> --
> Lukas Renggli
> http://www.lukas-renggli.ch
>
>

> Hi Stef,
>
>> I think that the audience of david is different than yours and
>> serving large flash or photoshop image by newbie that do not
>> know well apache is something that we cannot push on them. We are
>> writing a book for beginners and we should take that
>> into account. Not everybody is an apache expert. I'm not for example.
>> Still it may make sense to me to be able to serve large files that
>> are not in the image.
>
> certainly it makes sense, but Seaside is not about serving static
> files. Kom itself doesn't do that any better. So why using a
> complicated solution (that has no use in practice) when a simple one
> (that has no use either, but is simple and works well for prototyping)
> would do as well?
>
>> So did I understand correctly that we will have to create our own
>> distribution because you will not add the method I asked
>> david to do to hide some ugly parts of his setup to serve file?
>
> I don't mind to add a single method, but we try to keep Seaside as
> clean and independent of the underlying architecture as possible. The
> code used to serve files does not follow the idea of Seaside (and
> Smalltalk in general) and does not work together with anything else
> than WAKom on Squeak (there are two other ones available in Squeak,
> VisualWorks/Dolphin uses a different Web server).
>
> Cheers,
> Lukas
>
> --
> Lukas Renggli
> http://www.lukas-renggli.ch
>
>

> I share your sentiments. While the "purity" of Seaside is a noble objective,
> it should be more a guideline than a strict edict. Seaside should be more
> flexible in meeting the diverse needs of web development, because we all
> know that the *real* world of the web is not neat and tidy. It is messy and
> terribly makeshift. And it is NOT the job of Seaside to bring order to the
> world of web development. So, yes, let's have *easy* and *convenient*
> support for file serving. If you don't make allowance for developer
> convenience, you will unfairly limit Seaside's appeal.
>
> Note that this isn't the same thing as "dumbing down" Seaside. I'm saying we
> have to recognize the pragmatic realities of the web environment and
> infrastructure, and not cocoon ourselves within an artificially pure,
> enclosed world.
>
> Richard
>  

> FINALLY!!! I found the answer here:
>  
> http://inchingforward.blogspot.com/
>  
> | ma seaside |
> HttpService allInstancesDo:    [:each | each stop. each unregister].
> WAKom  stop.
> seaside := WAKom  default.
> ma := ModuleAssembly core.
> ma serverRoot: FileDirectory default fullName.
> ma alias: '/seaside' to:    [ma addPlug: [:request | seaside process:
> request]].
> ma documentRoot: FileDirectory default fullName.
> ma directoryIndex: 'index.html index.htm'.
> ma serveFiles.
> (HttpService startOn: 8080 named: 'httpd') plug: ma rootModule
>  
>  
> Seems like the configuring of the web server is very arcane and
> touchy! I'm going to have the above emblazoned on my forehead...  :-)
>  
> Regards,
> Richard
>  

> I don't think that  everyone is interested in being an expert at
> configuring wierdo linux technologies. I myself have no intention of
> ever having to write apache rewrite rules. If I ever have to then I
> figure something is wrong.
>
> Why do I think this way you might ask. It is simple, I am a mac user!
>
> Not that I cant do the "hard" stuff, I used to program my PC's in C
> back in '85 and mc code before that.
>
> The fact is that I don't want to.
>
> I don't know why everything is so hard. When you collect your images
> together, when you edit your images where are they? On disk, so where
> should you be able to serve them from by default. Yes thats right ON
> DISK.
>
> If you are fine tuning your site, editing you images what don't you
> want the browser to do? Thats right you don't want it to cache the
> images! Can seaside do this out of the box no it can't! Never mind
> accessing databases, seaside cant even serve files.
>
> Moving the file in-image is an optimization, and its quite nice for
> distributing a pre-configured image without lots of supporting files,
> but its not the simplest thing to configure or use. Throwing your
> files into a directory or a directory hierarchy is. And seaside cant
> handle that, despite, as I was told recently trying to embody the
> 80-20 rule, that is supporting the majority of what users want to
> achieve.
>
> So in terms of lowering the bar for newbies some things are basically
> obvious, but seaside has acquired an "elitist" approach. It appears
> that some things (like serving files) are beneath it, and "best left
> to apache". So it turns out that due to this elitism, seaside cant
> even do the basics out of the box. The purist mentality doesnt allow
> for the "seaside does what it does, and does it well" to be poluted by
> compromise positions which would make things more flexible and
> therefore perhaps more broadly usable. Serving files is but one
> example, using cookies for day to day site things is another, this
> facility almost disappeared from 2.8a unnoticed.
>
> Now I would like to be able to rectify this situation, but I have a
> distinct disadvantage, I don't write perfect code, I throw something
> together which does the job, I need others with different skills to
> refine and hone the result to perfection.
>
> So as it happens I have on numerous occasions attempted to submit code
> which addresses some of these (imho) shortfalls. And time and time
> again the purists reject much of what I have offered out of hand. For
> various reasons, some of them good reasons. Nevertheless I got tired
> of the continuous negative attitude that comes out in this "protecting
> the purity" of seaside.
>
> This has resulted in me making a complete ass of myself by loosing my
> rag (fortunately in private) at the maintainers. I have apologized,
> and if you have noticed that the seaside repository is now read only,
> thats probably all my fault that I pissed off the maintainers and I
> apologize to them and also to the community for that.
>
> But lets examine this a little bit, one example.
>
> Seaside configuration attributes are organized into groups. So the
> function "tell me if this application has the configuration group
> named x" (so I can add a dispatcher plugin to it). This function is an
> accessor into private information encapsulated within the seaside
> kernel so to speak. So in order to make this useful as a feature,
> whose responsibility would it be to provide an accessor? I would say
> the package that implements the feature should expose enough of that
> feature in a public api so as to be useful to users who want to use
> it. So I suggest #hasGroupNamed: accessor  to match its existing
> counterpart #hasAttributeNamed:
>
> The objection I am given is: "This is dangerous". Why? Because it has
> no users within the seaside core package, and having no users it is
> fragile and might break or be removed without anyone noticing. Well
> hang on, isnt that obvious! It isnt in the base package 'yet' so of
> course it hasn't got any users, its whole purpose is to be a public
> API so that clients and extensions to the base package can use it. Its
> reason for being that is to support users external to the core, not
> internal to the core, the internals probably dont need it since they
> can access the value directly etc. So somehow we have this statement
> of law which says "No public api shall be exposed which is not used
> inside the grey-box of the core, which incidentally doesnt need a
> public api anyway".
>
> So what if it does break? Well if it doesnt have any users inside the
> core seaside package, then who cares. Its not dangerous at all, if it
> breaks its not going to ruin anyones day. Ok so I, with three users of
> this api might miss it and flag if it becomes broken. But dangerous it
> is NOT.
>
> This really got my goat I am afraid, I attempted to put this accessor
> into the seaside repository 6 times or more. And it still hasnt made
> it past the idealistic police. Now I am not writing code or uploading
> to monticello for my health. Can you wonder why I got a little peeved.
>
> So if you are wondering why seaside doesnt make progress in attracting
> broader appeal, one possible answer is that the maintainers have a
> very narrow and purist perspective. Which is worthwhile, and serves a
> purpose to make seaside better in a certain focussed way, just not in
> the way that will broaden seaside's appeal (imnsho).
>
> So lets turn to the question at hand, serving files. What would it
> take to add this to seaside.
>
> 1 Method thats all! Where is it? Not there? Why not? because I guess
> serving files must be in the 20 of the 80/20 mentioned earlier. Who
> decides this? Well someone who likes configuring apache I guess.
>
> So in a three method varient a) subclass FileLibrary add an instVar
> fileNames and load it up with any resources you want to serve in-image
> as defaults which the files can then override.
>
> the methods:
>
> WAFileBasedLibrary-initialize
>
>    fileNames := self libraryDirectory fileNames
>
> WAFileBasedLibrary-libraryDirectory
>
> ^FileDirectory default directoryNamed: 'resources'
>
> WAFileBasedLibrary-documentAt: aFilename ifAbsent: aBlock
>      | doc |
>
>    (fileNames includes: aFilename)
>        ifFalse: [ ^ super documentAt: aFilename ifAbsent: aBlock ].
>
>    doc := (WACachedDocument
>            fileName:  (self libraryDirectory pathName, FileDirectory
> slash , aFilename)) asMIMEDocument.
>
>     ^  WAResponse
>            document: doc
>            mimeType: doc mimeType
>
> Bingo, now that wasn't hard was it, throw any files you want to serve
> into 'resources' directory and you are away.
>
> best regards
>
> Keith
>
>
> _______________________________________________
> Seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>

> Hey, lets look to the roots: Seaside serving http requests. And i can
> assure you, that for 99% of the users in the world, thing which
> serving http requests called web-server.
> You may call it web application development framework or anything you
> want, but this will not makes any difference unless you stop handling
> http requests.
> Its a layer, which delivers content to browsers using standard
> protocol and from this point of view, it must be flexible enough to be
> able to deliver any content which developer wants to.
>
> And you saying 'standalone web server'.. It looks like you insist that
> seaside in 90% cases in not complete solution for _BASIC_ web
> solutions?
> Why it must force developer to use third party tools to be complete?
> Its better to be slow, as hog but be COMPLETE rather than flexible,
> complex, but incomplete...