"PHP" sessions in PAWN
#1

So over the past few days, I've been thinking of some unique ideas to effectively share data across other scripts, when I came across this idea: sessions

Basically, in PHP, you can do this:

PHP Code:
<?php
session_start
();
$_SESSION['texta'] = 'dog';
$_SESSION['textb'] = 'cat';
$_SESSION['textc'] = 'fox';
echo 
$_SESSION['texta']."<br/>";
echo 
$_SESSION['textb']."<br/>";
echo 
$_SESSION['textc']."<br/>";
session_destroy();
?>
And I'm developing a PAWN library that allows scripters to do this:

pawn Code:
main()
{
    session_start();

    session_set("texta", "dog");
    session_set("textb", "cat");
    session_set("textc", "fox");

    print(session_string("texta"));
    print(session_string("textb"));
    print(session_string("textc"));

    session_destroy();
}
And with this library, scripters can share this data across all scripts using the session_get functions.

But the real million dollar question: is it worth it? It uses a single SQLite database to temporarily save and fetch values until the session is destroyed, but I want to know if using a SQLite database is the best choice or if there are any other alternatives.

What do you think about this idea?
Reply
#2

And.. how/where will the result be printed (pawn) ?
Reply
#3

Quote:
Originally Posted by Sublime
View Post
And.. how/where will the result be printed (pawn) ?
server_log.txt lol

But the session_get function will fetch from a single SQLite database (db_get_field_assoc) that can be used between all scripts.
Reply
#4

I think you should use a different method as IMHO SQLite may not be necessary. Something like a include file would be suffice? Would you be limited in the amount of session items you can have?
Reply
#5

It is well worth if people begin to use this in their script, tho I never saw anyone using this kind of stuff.
Reply
#6

Quote:
Originally Posted by Isolated
View Post
I think you should use a different method as IMHO SQLite may not be necessary. Something like a include file would be suffice? Would you be limited in the amount of session items you can have?
For now, there can only be one session at a time, but I was thinking of letting the scripter have as many sessions as they would like (indefinite) - all would save inside one database file (sessions.db).

Quote:
Originally Posted by Sublime
View Post
It is well worth if people begin to use this in their script, tho I never saw anyone using this kind of stuff.
Probably. A lot of people use the GVar plugin for sharing data across filterscripts for example, but this library I am planning up will be way more advanced than GVar, with the ability to save arrays, hex and boolean values, and also save data into an .INI file.
Reply
#7

I don't get it, is it like GVars or what?

Edit: Just read your latest post, so it is. I don't know why would you create something which is already possible.
Edit2: Why don't you just use GVar and make an include which uses GVars to make that INI saving stuff possible.
Reply
#8

Quote:
Originally Posted by Finn
View Post
I don't get it, is it like GVars or what?

Edit: Just read your latest post, so it is. I don't know why would you create something which is already possible.
Edit2: Why don't you just use GVar and make an include which uses GVars to make that INI saving stuff possible.
Well, it is a mixture of GVars and sessions from PHP, except that I've planned to make indefinite session ID's, a sorting feature, and an expiry time for values.

Edit:

Quote:
Originally Posted by Y_Less
View Post
PAWN has this ability natively in "properties", the GVar plugin already replicates something that exists, why re-replicate it? If you want something better than what even the GVar plugin offers, why not just fork and update the GVar plugin?

I'll also point out that there is y_master too, in which this can be replicated in seconds.

Edit: In fact, generally PHP sessions are per-user data, so you have PVars for that.
Good point, but I don't really use properties since there are better and more efficient ways to share data across scripts (I remember you said something about properties having the same loading and saving style as PVars). It's also hard to keep track of the data stored in properties.

I have to give y_master a try also, currently checking out this thread. I also had an idea in mind for my gamemode regarding NPC's, and y_master can really be useful in this case.

This thread can be closed. Thanks everyone!
Reply
#9

Quote:
Originally Posted by Y_Less
View Post
Something like this ENTIRELY UNTESTED code:

pawn Code:
some untested code here


quote by Y_Less
Reply
#10

Quote:
Originally Posted by SuperViper
View Post


quote by Y_Less
"If you are replying to a problem"

He was giving a brief outline of how something may be accomplished, not responding to a problem of the OP. I suspect you will be going around to every post in this forum now to point out this exploited rule, or did you only do it for him so you could gain some attention for yourself?

Quote:
Originally Posted by Emmet_
View Post
It's also hard to keep track of the data stored in properties.
How so if I may ask? You can write some simple macros to basically replicate the same effect of what you are trying to do with this library with properties.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)