Thanks for all the info guys. I'm thinking of having 2 scripts on the server side; 1 to get the dbase info to put it in a file (say every 20 minutes). The 2nd to read the file every 10 minutes and to respond to client requests for that info. That way, the clients won't cause lots of sql queries to the dbase when the client updates the view.
Humm... Maybe this could be an option for one of the configurable little apps they are looking for to show what REBOL can do. Have 1 script do the sql to get any results needed and output to file. Have "server" script read file and have info available for clients. Have client GUI's designed to display different sql results (depending on what you configure on the server). What do you guys think? I'm probably thinking of this wrong as I'm defiantly a newbe. John -----Original Message----- From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Gregg Irwin Sent: Thursday, June 01, 2006 11:31 AM To: John Blake Subject: [REBOL] Re: SOA Hi John, JB> How stable do yall think the SOA stuff is? As someone said, SOA is a concept, or a model, so "stability" doesn't really apply. Is it a sound architectural model? You bet. Of course, there's a huge gray area about what qualifies as SOA too. :\ REBOL was designed for messaging. You could easily write a little app that requests data via CGI, a direct server connection, RebServices, etc. and displays that. Piece of cake. Now, with REBOL, you can just as easily request a small script, so you're dynamically requesting the app to run, GUI and all. You could also use the browser plug-in to avoid deployment issues. -- Gregg --=20 To unsubscribe from the list, just send an email to=20 lists at rebol.com with unsubscribe as the subject. -- To unsubscribe from the list, just send an email to lists at rebol.com with unsubscribe as the subject.
