Translate scripts into commands on server

[Mike Doty]

How do you translate scripts passed in a client/server environment using "FOR/NEXT", "DO/WHILE" , "GET", "PUT", "OPEN", etc ... into code on a server? I have my own way of doing it and thought about a PB script compiler (dream.)


Added this after Michael's posting below.
This is for TCP client/server so the TCP server can perform tasks for the client.

[Michael Mattias]

>PB script compiler (dream.)

ThinBasic is a 'script interpreter'

VBA is a 'script interpreter'

Java is a 'script interpreter'

All these can execute "programming commands organized as a procedure or group of procedures" - 'mini applications programs' if you will.

Is that what you want to do, send a 'script' to some 'server' for execution?

That said, I think you have to select your 'script language of choice' and create your scripts in that language before sending for execution.

???

[Mike Doty]

No, I wrote the client and the server using TCP.

[Michael Mattias]

>No, I wrote the client and the server using TCP.

Ok, so your client creates and sends your script file to the server using TCP, and the server then calls the appropriate 'script executer' program.

What am I missing here?

--------------------------------
Still confused in America's Dairyland

[Mike Doty]

You are missing the script executor code.
What would the code be for:
FOR X = 1 TO 10: GET #3, X: NEXT

The server performs all I/O on the local files.
The client only sends strings to the server.
The client cannot directly execute anything on the server.
If a client wants to get record 1 from file 1 that string must
be translated by the server into a call like GET #1, 1.

The original question is:
How do you translate scripts passed in a client/server environment using "FOR/NEXT", "DO/WHILE" , "GET", "PUT", "OPEN", etc ... into code on a server? I have my own way of doing it and thought about a PB script compiler (dream.)
This is for a TCP client/server.

[Michael Mattias]

Well, your way - whatever it is - is as good as the next way.

Were I to undertake this type of project, I would just create my scripts in the syntax of my 'script language of choice' instead of another product's syntax.

After all, to do this project assumes you know BOTH languages, does it not? So why even bother with a 'translation?'

Eg instead of "FOR ..NEXT" I might use

  ASSIGN I, 1  
  DO 
       Something (I) 
       I+
  ENDDO

MCM

[Mike Doty]

The point is to have a common syntax so everyone can easily write
client/server applications without inventing their own command set.

[Michael Mattias]

I must still be missing something.

The common command set *is* your 'script language of choice.'

If you want to make that 'script language of choice' a BASIC dialect, you'll have to tell your server software what to do when it sees "FOR .. NEXT" or OPEN or any other keywords you choose to support.

(This is exactly what ThinBasic does).

If you are talking about a server-based PowerBASIC Compile/Execute, first thing I'd do is check with the people in Florida to see if you need a special license. (I think something akin to this has come up here before).

MCM

[Mike Doty]

I'm trying to have a standardized library of TCP requests. If a third-party library knows how to directly open a file in PowerBASIC and get records
198 through 209 and then close the file without using anything other than TCP is the goal. The goal is to standardize this so SQL or third-party software is not required. I will continue to roll my own. No Java, no VBA, just PowerBASIC. I will contact support about this. Thank you.

[Michael Mattias]

I'm trying to have a standardized library of TCP requests. If a third-party library knows how to directly open a file in PowerBASIC and get records 198 through 209 and then close the file without using anything other than TCP is the goal.

Then why didn't you say so?

The key to this IMO is a design which supports this as an alternate service provided by your server software. (Yes, I know that is redundant, but bear with me a moment here).

In this case it does not quite make sense to me why you'd call a server to open a file and get a certain set of records when you could just open the file and get those records directly from your program... what you say the client program can do.

But if you mean THE SERVER calls the third-party library, then you could make up a 'generic' command to be sent via TCP, something like

EXECUTELIBRARYFUNCTION  Commandname  commandoptions

For example, you might call the server with

EXECUTELIBRARYFUNCTION   GetRangeOfRecordsbyNumber  "198 209 myfile btrieve"

...Which tells the server to get records 198 thru 209 from file 'myfile' and that "myfile" is a Btrieve file. Your server then translates this into the requisite btreive calls and returns the records in some defined format.

But if the client can do this himself, I don't know why the server even has a job.

Or maybe you want to do something like

EXECUTEDLLFUNCTION  libname, procName, param [,param]..

This would be a way to make some service not otherwise available to that client available... or to hide "how it's actually done" if that is desireable, as you could make your own translations for "libname" and "procname" and the client would be none the wiser.

Maybe a little more specific example?

MCM

[Mike Doty]

I don't know how many ways to state the same thing.
It is good to have new ways of doing things available.
So many command sets, why not a new one just for PowerBASIC TCP client/server programming? We have FTP, SMTP, NNTP, POP3 and so many more. Why not a CLASS? Contacted support if they have any mini or pre-compiler available. SQLite has an interesting byte code.
How about TCP Tools?

[Michael Mattias]

I think you replied while I was finishing up after prematurely hitting 'post.'

"Client/server" is it's own architecture; TCP is just one way of implementing that architecture. Its use is dictated by the application: access to a centralized repository of data, or some business rule implementation which is often revised and it's a lot easier to change one server than to change ALL the users (clients).... stuff like that.

If an application is not ripe for a client/server architecture, making it "TCP Client server" is not going to be the best choice either.

[Mike Doty]

Why are you saying this? What benefit does this have to this posting?

[Joe Byrne]

Maybe its something in the water ....

I'm not really following what you're after either Mike. Can you expound on the concept further?

[Mike Doty]

Instead of the code below a predefined command set or parsing method.

Roll your own:'
TCP RECV [I]fNum&[/I], [I]count&[/I], [I]Buffer$[/I]
IF Buffer = "GET" THEN 
  CALL GETROUTINE parameters
ELSEIF Buffer = "PUT" THEN
  CALL PUTROUTINE parameters
ELSE 
END IF

[Michael Mattias]

>Instead of the code below

This is server-side code, right?

Why replace it? It looks pretty good from here.

Or do you mean something like, '"PUT" or "GET" imply using a file previously opened with an "OPEN" command (buffer="OPEN")???

You can do that, you just have to keep track of who has what file open and where the file pointer is.

{ADDED}

Maybe you can show a little suggested "client-side" pseudo-code? That is, what you are desirous of supporting?

[Cliff Nichols]

I think I get where Mike Doty it going with this.

Do you mean, that you write some client/server program, but allow me to write a text script that could do something like

For i = 1 to 5
     Open Connection Yadda(i)
next i

And I not care what language you wrote the program in? nor you caring what language (or script) I am calling it from????

[Mike Doty]

Yes, that is correct.
The client is in PowerBASIC, but the client could be in another language if it knows the format of the send/receive buffers.
Only the server is allowed any access to the data files (which you all know.)

I haven't seen any postings on how others layout their send and receive buffers or parse out commands and process them. I was trying
to come up with a better way. I'm going to study some web server code and see if I can adapt that. Currently, I just makeup commands.
There is nothing wrong with this except I would rather have a standardized set of commands. I see some use a 2-dimensional array and
think in datasets which is fine. It would also eliminate the need to keep record position and current key number for each connection if access is only
allowed within a transaction. The first access would establish or reestablish the record and key position for each connection.

[Michael Mattias]

The client is in PowerBASIC, but the client could be in another language if it knows the format of the send/receive buffers.
Only the server is allowed any access to the data files (which you all know.)

???

The source language of the client program should not be material at all. If that client can send a command to the server - by TCP or any other method you choose to support - the server can respond.

It sounds to me like you currently have a very workable server solution.

> think in datasets which is fine.

RDS (remote data services) ??

[John McWilliams]

Way to Complicated

Mike you are getting bogged down in the minutia. Just listen on a port and wait for a formatted command to come in and then execute it (security hole?). Who cares what language sent it? I've been doing stuff like that for years. I use an authentication procedure to verify who sent the request (and I journal it) before I act on it. But I just listen on a port and as long as the "message" fits the format and the client is authenticated then it gets done. I do something like this:

MachineName:UserName:Request:TimeToExecuteTheRequest:IPAdressTo ReturnTheInfoTo:Authentication

If the request doesn't meet the format or doesn't authenticate, I ignore it.