Announcement

Collapse
No announcement yet.

Translate scripts into commands on server

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Translate scripts into commands on server

    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.
    Last edited by Mike Doty; 3 Feb 2009, 09:19 AM. Reason: Added this is for a TCP Client/Server

  • #2
    >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.

    ???
    Michael Mattias
    Tal Systems (retired)
    Port Washington WI USA
    [email protected]
    http://www.talsystems.com

    Comment


    • #3
      No, I wrote the client and the server using TCP.

      Comment


      • #4
        >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
        Michael Mattias
        Tal Systems (retired)
        Port Washington WI USA
        [email protected].com
        http://www.talsystems.com

        Comment


        • #5
          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.
          Last edited by Mike Doty; 3 Feb 2009, 09:30 AM.

          Comment


          • #6
            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
            Code:
              ASSIGN I, 1  
              DO 
                   Something (I) 
                   I+
              ENDDO
            MCM
            Michael Mattias
            Tal Systems (retired)
            Port Washington WI USA
            [email protected]
            http://www.talsystems.com

            Comment


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

              Comment


              • #8
                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
                Michael Mattias
                Tal Systems (retired)
                Port Washington WI USA
                [email protected]
                http://www.talsystems.com

                Comment


                • #9
                  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.
                  Last edited by Mike Doty; 3 Feb 2009, 10:40 AM.

                  Comment


                  • #10
                    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
                    Code:
                    EXECUTELIBRARYFUNCTION  Commandname  commandoptions
                    For example, you might call the server with
                    Code:
                    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
                    Code:
                    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
                    Last edited by Michael Mattias; 3 Feb 2009, 10:58 AM.
                    Michael Mattias
                    Tal Systems (retired)
                    Port Washington WI USA
                    [email protected]
                    http://www.talsystems.com

                    Comment


                    • #11
                      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?
                      Last edited by Mike Doty; 3 Feb 2009, 11:02 AM.

                      Comment


                      • #12
                        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.
                        Michael Mattias
                        Tal Systems (retired)
                        Port Washington WI USA
                        [email protected]
                        http://www.talsystems.com

                        Comment


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

                          Comment


                          • #14
                            Maybe its something in the water ....

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

                            Comment


                            • #15
                              Instead of the code below a predefined command set or parsing method.
                              Code:
                              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
                              Last edited by Mike Doty; 3 Feb 2009, 12:46 PM.

                              Comment


                              • #16
                                >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?
                                Last edited by Michael Mattias; 3 Feb 2009, 05:02 PM.
                                Michael Mattias
                                Tal Systems (retired)
                                Port Washington WI USA
                                [email protected]
                                http://www.talsystems.com

                                Comment


                                • #17
                                  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
                                  Code:
                                  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????
                                  Engineer's Motto: If it aint broke take it apart and fix it

                                  "If at 1st you don't succeed... call it version 1.0"

                                  "Half of Programming is coding"....."The other 90% is DEBUGGING"

                                  "Document my code????" .... "WHYYY??? do you think they call it CODE? "

                                  Comment


                                  • #18
                                    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.
                                    Last edited by Mike Doty; 3 Feb 2009, 06:23 PM.

                                    Comment


                                    • #19
                                      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) ??
                                      Michael Mattias
                                      Tal Systems (retired)
                                      Port Washington WI USA
                                      [email protected]
                                      http://www.talsystems.com

                                      Comment


                                      • #20
                                        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.
                                        Last edited by John McWilliams; 4 Feb 2009, 06:25 PM.

                                        Comment

                                        Working...
                                        X