Board.KolibriOS.org

Начал думать насчет CGI интерфейс для phWeb сервер. И так как этот интерфейс работает через STDIN/STDOUT, то надо чтобы перенаправлять ввод/вывод к серверу. Насколько я знаю, консольные приложения в Колибри пользуют "console.obj". Перенаправлять нужно каждую программу независимо и одновременно - так как сервер может выполнять несколько скриптов одновременно.

Так, возможно ли реализовать это, чтобы было совместимо с console.obj или нельзя и надо делать своя спецификация?

Может лучше сделать SCGI http://python.ca/scgi/protocol.txt ? Он намного более минималистичен, и рассчитан на скорость работы. И вместо STDIN/STDOUT лучше использовать "пайпы" в виде разделяемой памяти. Например, как этьо сделано здесь - viewtopic.php?f=48&t=1111&start=90#p40875

SCGI будет, только он (как и FastCGI) задуман и в конечном счете подходит, только для большие приложения, которые очень нельзя выполнять в виде процессов - например PHP и Perl интерпретаторы и др.под. CGI скрипт, поддерживающий SCGI или FastCGI это по существу специализированны сервер, который работает все время и выполняет заявки от web сервера.

А насчет консолью, я посмотрю как это реализовано в существующем шэлле и постараюсь сделать чтобы было совместимо. Хотя и мне кажется, что пайпы должны поддерживаться в ядре.

In Network branch kernel, it should already be possible to use a socket to communicate between different applications.
Use address family UNIX (1)

hidnplayr wrote:In Network branch kernel, it should already be possible to use a socket to communicate between different applications.
Use address family UNIX (1)

So, you suggest to use sockets for console input/output? It is probably not a bad idea, as long as the sockets are pipes actually. But how the started application will know the address/port of the "console server"? There can be any number of them working simultaneous.

I just checked, they are not yet implemented as fully as i tought they were, sorry to have misled you.

Here is a brief description: http://en.wikipedia.org/wiki/Unix_domain_socket

I need to implement the socketpair function and finish some other code in sockets.inc before it can work.

I do not really understand what 'console' window you are talking about, the text window on the server computer ?

hidnplayr wrote:I do not really understand what 'console' window you are talking about, the text window on the server computer ?

As "console", I mean the application which will accept console program output and send the console program input. It can be normal console window application that will output the received output to the screen and will send keystrokes to the console application, but it can be also web server that will send the output to the network and will send the requests to the CGI script (which is console application actually).

The console interface should be able to support all these variants in one consistent way.

I believe a correct implementation would be to start an application with as argument the pointer to the console (Be it a socket, named buffer or something else)
If no arguments are passed, the applications should open a new console, preferably through console.obj (or it's newer variant)

The implementation of a real console system would greatly enhance the capabilities of kolibrios, go for it!

If I understand correctly, this UNIX address family uses some kind of different addresses. Not IP/port pair. But what these addresses look like?

BTW: What are the plans about including the new network branch in the trunk?

johnfound wrote:If I understand correctly, this UNIX address family uses some kind of different addresses. Not IP/port pair. But what these addresses look like?

BTW: What are the plans about including the new network branch in the trunk?

You need no adressing, you call socketpair and it returns two socket pointers. The two sockets are already connected to eachother.
One is to be used by the local app (calling the function) and the other can be used by another app.

Then you can simply use send an receive

hidnplayr wrote:You need no adressing, you call socketpair and it returns two socket pointers. The two sockets are already connected to eachother.
One is to be used by the local app (calling the function) and the other can be used by another app.

Then you can simply use send an receive

Ah, I got it. So, I have to send 2 or 3 numbers to the child application - STDIN, STDOUT and STDERR, allocated by the parent application, right? Or maybe only two STDIO and STDERR...

It would be the best, if the transfer of these numbers was organized by the kernel - for example by using respective fields in the application header and passing these numbers directly to the fn.70.7
Now I have to pass them through the command line parameters, using ASCII string.

One socket provides two-way communication so only two numbers are needed indeed.
You propose to create a new application header specific for console applications? I think it's a good idea.

hidnplayr wrote:One socket provides two-way communication so only two numbers are needed indeed.
You propose to create a new application header specific for console applications? I think it's a good idea.

Why only for console applications? To have several communication channels is good for any application. At least does not hurt. If the parent application does not want to use this mechanism it can simply pass NULL in these fields. The header version field could serve the purpose to indicate the presence of these fields.

The function 70.7 has two reserved fields with offsets $0c and $10 - they can be used for this purpose. This use will provide backward compatibility as well.

But it is serious changes, what other developers think about it?

Так, что думают ведущих разработчиков насчет таких перемен? Я может быть и возьмусь реализовать, только надо освоить SVN сначала.