Rev cgi search question

Tue Jan 15 17:05:15 EST 2008

Thanks, Andre, for the extensive reply. I'll study it and get back to  
you if I have any questions.
Richard

On Jan 15, 2008, at 10:47 AM, Andre Garzia wrote:

> Richard,
>
> using 'launch' is not advisable. Not only every instance of your cgi
> will start it's own program but there's a big chance that your cgi is
> running as 'nobody' or 'apacheuser' or some other very limited user on
> your server (this is a good thing, it's security wise to put the cgi
> user on a sandbox of sorts). If you want to run a persistent software
> on your server, you must do it with text file scripts and revolution,
> trying to run stacks or standalones will try to connect to the X11
> server and unless you're running a framebuffer display server, this
> will fail and your software will fail to start with it.
>
> If you're thinking about running a software to cope with your previous
> search result issue, then let me say that you don't need it.
>
> The idea to solve this kind of trouble is to have session variables.
> This variables are assigned to each of your clients and you can store
> useful information in them. Revolution does not provide us with
> session variables from the start but with minimal effort you can
> create your own. In my RevOnRockets package (
> http://www.andregarzia.com/RevOnRockets ), I have a minimal
> EasySession library that can help you.
>
> My current session library implementation is not in sync with
> EasySession. What I am using today is plain stack files. Each stack
> file holds a session. The name of the file is a unique id and I pass
> this name in the SessionID url parameter or a cookie. I have two
> functions one for setting a value and one for getting a value. My
> library has lockfile features, so a user with two browser windows open
> (and maybe the same session on both) will not overwrite himself.
>
> whenever I need to store some value, I call my value setting function
> which not only sets the value taking care not to overwrite other
> changes being made but it also save the file, so once the value is
> set, it is not lost anymore. Getting values is easy, we don't need to
> check anything, we just pull the value from the stack and thats all. I
> use custom properties to hold values.
>
> You may ask, "Why, Oh Brazilian Fool, are you using stack files
> instead of a database?" and the answer is quite simple. First, I like
> stacks. Second, session variables don't usually need heavy concurrent
> access or fort knox level security. You just use it to store simple
> data, if you need security you use a database and make a pointer in
> the stack file like myDatabaseId = '#23525' so your database record is
> safe and your session still contains the parts needed to construct the
> information you need.
>
> The main benefit of databases in my very humble opinion are:
> * many users changing the same resources.
> * searches!
>
> With session variables you have only one user changing his own session
> and you don't need searches, so, I guess we don't need a RDBMS
> afterall.
>
> Now, there are other ways if you digg into Javascript. You can use a
> hidden div to hold all your search data and use javascript in
> combination with xmlHTTPRequest to move things around. I don't know if
> this is overkill though.
>
> The RevOnRockets package comes with EasySession that uses text files
> instead of stack files and has no lockfile features so it is possible
> to overwrite changes if a user has two browser windows open with the
> same session. Still it is good enough for simple sessioning. With
> EasySession each session is write-once-read-once, or in plain english:
> you set a session then you read it afterward and when you read, it is
> deleted, if you want to move what you read forward then you need to
> set it again. This was done for security purposes so that sessions
> can't be re-used. If some hacker picks your url with a session id,
> there's no problem because that session has a great chance of not
> existing anymore.
>
> So what easy session is good for? Moving secret data from one page to
> another. In one page you set the data, for example credit card number,
> user information and when moving to the next one, you pass the session
> id. In this page, the data is read and session is cleared. Your url
> and your post/get requests hold no sensitive information. I've created
> this library mostly for doing confirmation pages where the user fill
> data, then he is moved to a confirmation page, then the data is
> proccessed. This way, I simply set the session on one page and clear
> it on the next, the sensitive data is held on server for a very brief
> time, just the interval when the user is in transit from one page to
> the other since in each page the session is cleared. It is hard to
> capture this session and impossible to re-use it. Feel free to
> download RevOnRockets and check on EasySession.
>
>
> I hope this helps.
>
> Andre
>
>
> On 1/15/08, Richard Miller <wow at together.net> wrote:
>> Thanks.
>>
>> A few other questions about using Rev in the cgi-bin.
>>
>> Can a Rev cgi script use the "launch" command to run a small Rev app
>> from inside cgi-bin?
>>
>> Do I understand correctly that several instances of the Rev cgi
>> application can be running concurrently? In other words, the server
>> could be simultaneously processing the requests from several users,
>> but each request would cause the Rev app to start its own instance.
>> Is that right?
>>
>> Thanks.
>> Richard
>>
>>
>> On Jan 14, 2008, at 8:41 PM, Kee Nethery wrote:
>>
>>> We do stuff like this all the time. caching data locally.
>>>
>>> The deal is we store last datetime changed for each row in each
>>> table in our database. Every time the row gets changed the datetime
>>> gets updated.
>>>
>>> The various systems that use the data search the local data cache,
>>> not the external database.
>>>
>>> Before doing the search we do an update to the cache and to do that
>>> we keep track of the lastdatetime when the database was looked at
>>> and we look for any rows that have changed since then. If the
>>> result set is zero, then the cached data gets used as is and the
>>> lastdatetime gets incremented in the cache.
>>>
>>> If the resultset is not zero, we grab the changes, and incorporate
>>> them into the data set and then update the cache date.
>>>
>>> Then once the cache is updated, we do the search.
>>>
>>> If the cache is empty, or the last cache check date is empty, we do
>>> a complete pull from the database.
>>>
>>> Kee
>>>
>>>
>>> On Jan 14, 2008, at 11:28 AM, Richard Miller wrote:
>>>
>>>> I'm looking for suggestions on how to accomplish the following.
>>>>
>>>> 1. User starts a search of my text-based database (via browser and
>>>> Rev cgi).
>>>> 2. My app finds the results (which are a series of line numbers...
>>>> possibly as many as 1000)
>>>> 3. I now want to store those results so that when the user brings
>>>> up a data page resulting from the search, they can go back to the
>>>> results (presumably to go to another data page from the results)
>>>> without having to re-do the search or use the back-button on their
>>>> browser. I know how to store the results within a link (i.e.
>>>> http://www.results.com?results=1,2,3..."), and I'm using this in
>>>> various places already. But this won't work for me in all cases.
>>>>
>>>> I'm guessing one solution might be to issue a temporary id number
>>>> and connect that to a given users search process. The results
>>>> could then be stored in a file on the server under this ID, with
>>>> this page liquidated after some period of time (30 minutes? 60
>>>> minutes?). Would this work or is there a better way to handle this.
>>>>
>>>> Thanks.
>>>> Richard Miller
>>>> _______________________________________________
>>>> use-revolution mailing list
>>>> use-revolution at lists.runrev.com
>>>> Please visit this url to subscribe, unsubscribe and manage your
>>>> subscription preferences:
>>>> http://lists.runrev.com/mailman/listinfo/use-revolution
>>>
>>>
>>>
>>>
>>> -------------------------------------------------
>>> I check email roughly 2 to 3 times per business day.
>>> Kagi main office: +1 (510) 550-1336
>>>
>>>
>>> _______________________________________________
>>> use-revolution mailing list
>>> use-revolution at lists.runrev.com
>>> Please visit this url to subscribe, unsubscribe and manage your
>>> subscription preferences:
>>> http://lists.runrev.com/mailman/listinfo/use-revolution
>>
>> _______________________________________________
>> use-revolution mailing list
>> use-revolution at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your  
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-revolution
>>
>
>
> -- 
> http://www.andregarzia.com All We Do Is Code.
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your  
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution