work-flow-Initiative

Evaluation section:

0

Категории

work-flow-Initiative

Date of publication: 2017-10-17 12:05:09
Дата модификации: 2017-10-17 12:07:14
Views: 2785
Author: Мета Гость

Long ago WFI represented the unidirectional console CGI script written in high level language PureBasic, spinning under the Apaches and weighed 14 kilobytes.
Over time, little developed, took on more functions began generit pages using HTML templates and configuration files, and later started a little rabotats base and in general, then all arranged, except that as the load started to eat off a lot of resources, and not every well times to generate a page by re-run one and the same EXEshnik.
Work began on sdruzhivaniyu him while gaining momentum FASTCGI, worked for some time under lighttpd and more on something I do not remember and then we realized that we wanted to have a full protocol support FASTCGI and work with NGINX as a service, with all the attendant charms, good version appeared NGINX server under windows.
Actually WFI cross-platform, but need to continually take it under windows do not add to the desire to collect version running in parallel and without dynamically developing product under LINUX, but we'll get to the prodakshenom, besides also now fully supports UTF-8.
How would WFI at that time was just a little script, which encompasses the content management system with the admin unpretentious and we wanted to highlight this in the admin area of a separate module, and if you want to be able to add new modules and we do not notice as WFI from a script generating WEB Pages turned into a full-service WFI-server, which had only the explanatory work among the many who grew up around the modules, such as at the same time the server is now fully a task and many began to support recursive call modules.
Next WFI rid of all the functions linking it with the work of any particular project, that is, the shell became the same for any of the existing, but at the same time cardinally different projects, providing access modules each of them to the internal functions, protocols and API functions. Currently running one service can serve only one project, it may be a few sites, but must be based only on the same modules, but already laid some of the functions that will in the future to handle many different projects simultaneously.
Then, incredibly, we finally realized that on the basis of WFI can obsolyutno all:

You can generate any content on the go, whether it's web page, robots.txt, javascript, image, video streaming, everything depending on the conditions of interest (eg latch on google's search robot Friday summer, let admires the new design).
For example one can open port 80 to simultaneously use the protocols FTP, SMTP, POP3 (so we indulge, but now abandoned built in web server for NGINX better yet, neither of which has been invented)
* Use any programming language and therefore use any technology, and thus interact with any hardware (do seismograph disconnected during repair)
Implemented in one of the projects background tasks when tazhelye sql requests are queued and executed without waiting for the completion of the main flow.
Got an idea? write in the comments and we will consider whether it is real and answer)

Before implementing the multi-project is scheduled usovershesntvovat API interface, modify the function modules enable you to interact with each other directly, maybe add your own HTML-embedded template code language in the appendage to the existing special teams and finally finalize a feature lets you use the server WFI virtually any language programming, which is very appreciated programmers are not familiar with web development and eager to create sites on the long-familiar \ familiar \ favorite programming language.
Now WFI-server and WFI-CMS (dvizheиk this site) uses the following features.
COOKIE
AJAX
JAVASCRIPT
XML-RPC
JSON
FASTCGI
. . .

Evaluation of the document:

0

Article description: History of the appearance of the engine and server WFI site work-flow-Initiative