Because.
Powerful web utilities allow you to build secure and performing websites with fpc (also compatible with delphi).. but it is much more than that. We offer several utilities and algorithms for intranet, internet, string, http, parsing, and more.What is the current home page or project page?They are a programmer's dream since the API is simple and easy to use, while still letting you override defaults and get down low and dirty when you need to. i.e. secure by default.. but access to custom web headers, custom parsing, custom filtering, custom POST/GET, and custom everything.
Some phrases that describe powtils:
internet, parsers, string filtering, libraries, tools, http fetching and sending, email utilities, security, cgi, cookies, sessions, database, api, easy configuration, embedded, router, webserver, compact, minimal, tools, utils, freepascal, ruby alternative, php alternative, asp alternative, modern pascal, delphi, kylix, fpc, precompiler, compiler.
Many of the utilities work in desktop software too, allowing one to reuse offline software code in online web programs.
http://z505.com/powtils/idx.shtml
Live User Fed Documentation. Developers are usually the users of software too, when the software is good. Everyone is a user of a good product.. even the programmers who create the software.Why not put everything onto a PHP Mediawiki instead of lufdoc?Documentation is user driven.. rather than say driven by some developer who doesn't even use his own API. Many times users and developer-users know much more about the software than the pure programmer who doesn't even use the software.
Live online documentation is important (compared to dead offline docs) so that docs never become outdated. Static snapshots of documentation for offline browsing of course can be made too.
Eat your own dog food.. the lufdoc engine and this page you are reading right now is served by a Powtils program.
Why not just use a pair of stained panties to scoop food into your mouth instead of a fork or spoon? Because it will end up scattered everywhere on the floor. Because wikis are not designed for documentation. Because wikis are not structured.Lufdoc is better for documenting projects.. it is a documentation repository that is central, easy to use, geared and structured toward documentation. It is combined with the power of automatic source documentation generation tools.
Is this a wiki?
Is your your left arm a wiki? It seems that everything is a wiki these days. Delete that word from your brain. Wikis are terribly structured single namespace areas to throw up random pages. This lufdoc system on the other hand is dedicated to be structured, to be easy to manage, and to assist rapid editing of documentation or APIs.What is used to generate documentation declarations and notes?It is not just some plain freehand wiki with empty blank starting pages for everything. For example it is not a mediawiki.
LUFDOC wraps notes, verbose documentation, and comments around pages containing procedure, function, and structure declarations that were automatically generated from source files. Wiki's are completely freehand, whereas LUFDOC forms and mends around source code declarations as pasdoc/fpdoc do. However, of course you can start a new freehand page with lufdoc too, if the document does not relate directly to any code declaration, API call, etc.
FPDOC is used to generate the declarations for viewing.. and once that is done then the fun begins. Contributed notes can be edited online and comments can be added by users passing by. The docs can be searched.Notes can also initially be edited offline and then uploaded in batch through FTP into a folder. However the idea is for the docs to be all in one place online and live, easy to edit.. collaboratively . the idea of a server storing the data in one place rather than 53 developers having 120 patches on their own individual computers that all get out of synch.
You can put a password on all pages if you don't want normal people editing notes directly, but can still allow them to comment or add tips beneath the notes. Trusted users can have more privileges.. but the idea still is to let the occasional person passing by be able to make a comment or contribute easily to the docs. What is in it for them? It must be extremely easy, or they ain't going to help.
Why not just submit patches to the developer of the units each time a documentation update is available?
Or just recompile the docs and re-upload them to the server each time?
That's complicated and takes lots of work. Programmers have better things to do. It's like saying why do we use email when we could just personally drive over to the person's house and submit a paper copy each time in a nice cute blue envelope? Would it be easy to submit corrections by postal mail, compared to better tools like live phones or email programs? It's about the rapid speed of communication and cooperation.Why is RDD (rapid documentation development) better than traditional methods?Why do we edit, compile, link, and make programs all in one step instead of doing each step individually as some do with GCC/C/C++? Compiling, linking, uploading the docs, viewing them, and sending a patch all in separate steps is not something anyone wants to do since it is inconvenient.
LUFDOC is about rapid documentation development. It is not about 'fragmented documentation development' where we run around chasing different files in four different parts of the hard drive, then recompile these files, then link them, then log in to FTP, then upload them, then check them in a web browser, then run a patch tool, then send a patch, then get an email saying the patch isn't perfect and it may take 50 days for the patch to be applied, then repeat these steps 145 times a week every time a new tip or comment needs to be added to the docs.
Developers and users don't have time for creating patch files for docs, nor do developers have time to submit bug reports to update documentation that is located on some other website not near the bug tracker. By the time that even begins to happen, the developer passing by the docs has already left, or lost attention. Especially if there are no instructions stating that errors in the docs should be reported to so and so.Why was LUFDOC source code not released as soon as it went live?This is what usually happens:
Bah, let them fix the docs. Too much work for me to do it right here since there is no way of contacting them easily. Last thing in the world I'm going to do is get some patch program and send them a diff.. heck my email client isn't even running and I don't know if they'd reject the patch or whether I'd have to find the appropriate mailing list or bug report section. The patch might take 50 days to finally get into the docs or even 300 days to show up.. Not worth it, and too much work, bye now.What is in it for the person passing by? Why would he take extra efforts to help with the docs if it is torture for him to help with them? Step into his shoes.. the lazy person passing by who's got to get back to programming immediately and doesn't have much time to fiddle around just to add a tip or note to some docs...
Even having the user fire up his email client to submit a patch, or having him get an SVN account first would be horrid and terrible for him. Just say no to fragmented patching/updating of documentation. There are just less steps involved and more motivation for developers to write docs when the steps that need to be taken to update and fix the docs are easy and convenient.
It is not feature complete, and didn't have time yet. The author does not believe in always releasing incomplete alpha products early. Initial impressions can be made about a product (that sucks, doesn't have feature ABC and XYZ!). Everything that you've read about bazaar vs cathredral, where a bunch of monkeys release broken source code early.. is wrong. The product should at least be tested and somewhat stable with important features implemented, before it is released to the critical judgmental public who will only over analyze and misinterpret the software to death.What typical problems occur in the email/wiki community that lufdoc solves?
Sometimes users end up documenting the software through email lists and through newsgroups accidentally.. and the notes/memos in the emails or newsgroups never get merged into the actual documentation.. since the documentation writers are busy doing other tasks, are too lazy to fire up their documentation link/compile/upload system, or they just didn't acknowledge the email or newsgroup posting as potential documentation.Convenience and organization?Emails that suggest or imply 'should we put this in the docs?' rarely end up being put in the docs and the emails are forgotten about. Worse, sometimes it is not even suggested that tips be put into docs, because there is no easy way of putting the tip into the docs.. it is torture to do so. When lufdoc is available, someone simply shouts:
Oh let's immediately put this tip you just gave into lufdoc. Here is the convenient lufdoc url. Let's put your tip in the docs right now while our attention span is high, otherwise it'll never get done.'Instead of hesitating and delaying updating the documentation.. lufdoc is live and ready to serve immediately awaiting any notes/tips. Instead of documentation begin a terrible lonesome experience, it is fun, easy, and social with lufdoc.
It is better to have a structured place for us all to contribute to documentation conveniently. Newsgroups, mailing lists, wikis are the easiest way for many users to document software.. but this is why a lot of projects end up having terrible documentation but great mailing lists, newsgroups, and wikis. LUFDOC turns all the missing unstructured scattered docs into structured ones. It's a replacement tool to be used whenever someone has that urge to (unconsciously) throw some documentation into a wiki, email list, or newsgroup. Just as bugs shouldn't be stored in a wiki or email list, and are better off in a structured repository.How can I edit these docs?
Look for a "comment" and "edit" link at the bottom of the page when available. Right now these docs are being edited by certain people only and this software is in Alpha testing for a few developers only.