Menu
▾
▴
tclhttpd-users
|
From: Nicolas B. <ni...@ma...> - 2004-10-07 09:16:26
|
Hello, A quick sanity check from tclhttpd users would be appreciated.. We have developed a web-db, data entry app that uses tclhttpd to "proxy" read/writes to a Metakit db, in-process; not as a cgi call. We have about 10 users that use the db, most of the time, 1-3 users might be reading/writing at the same time.... My question is: I am aware that metakit is basically a single user db, but as I said, it is run under tclhttpd.. Is there any potential problem in using this approach. As much as I understand, "tclhttpd" is my "single user", and that read/writes are sequential/serialized, the equivalent of opening a console and playing with the mk db... We are running single threaded tclkit, with the stripped down tclhttpdmin.kit for the web-server, on a debian3 box I discussed this approach w/ JCW, and he seems to feel that this approach should not create any mk problems, but want to run this by this list. A few key points about the app. 1. A .tclaccess file permits access to the db 2. From then on, ncgi package is used for user_id and all form variables 3. The whole app uses self-posting .tml pages, with Doc_Redirects to the next page... regards and thanx in advance, nicolas boretos |
|
From: Colin M. <co...@ch...> - 2004-10-07 10:47:50
|
On Thu, 2004-10-07 at 19:14, Nicolas Boretos wrote: > As much as I > understand, "tclhttpd" is my "single user", and that > read/writes are sequential/serialized, the equivalent of opening a > console and playing with the mk db... That's a good way to look at it. > We are running single threaded tclkit, with the stripped down > tclhttpdmin.kit for the web-server, on a debian3 box Debian and tclhttpd? You are clearly a man of discretion and good taste. :) > A few key points about the app. > 1. A .tclaccess file permits access to the db Wrong place. Should be a .tml file (just dir/.tml is sourced in.) > 2. From then on, ncgi package is used for user_id and all form variables > 3. The whole app uses self-posting .tml pages, with Doc_Redirects to the > next page... I like this approach, I like .tml pages. Handling state through Redirects is a pain though. Perhaps we should come up with a nicer abstraction to cover the messy details of building systems of DFSAs to represent interactions via templates. One facility you should become familiar with is [Httpd_Suspend] and [Httpd_Resume], which allows you to leave the connection open (for some period) while processing other incoming connections. It might be useful in this application. -- Colin McCormack <co...@ch...> |
|
From: Nicolas B. <ni...@ma...> - 2004-10-07 14:03:39
|
Colin McCormack wrote:
>On Thu, 2004-10-07 at 19:14, Nicolas Boretos wrote:
>
>
>
>>As much as I
>>understand, "tclhttpd" is my "single user", and that
>>read/writes are sequential/serialized, the equivalent of opening a
>>console and playing with the mk db...
>>
>>
>
>That's a good way to look at it.
>
>
So, does this mean you feel that I should not have concurrency issues w/
th mk?
>
>
>>We are running single threaded tclkit, with the stripped down
>>tclhttpdmin.kit for the web-server, on a debian3 box
>>
>>
>
>Debian and tclhttpd? You are clearly a man of discretion and good
>taste. :)
>
>
>
>>A few key points about the app.
>>1. A .tclaccess file permits access to the db
>>
>>
>
>Wrong place. Should be a .tml file (just dir/.tml is sourced in.)
>
>
I'm not sure I get it;-(...The .tclaccess file calls the browsers login
stuff...I'm not sure that a .tml file is designed for this
Or, am I mis-understanding you...
>
>
>>2. From then on, ncgi package is used for user_id and all form variables
>>3. The whole app uses self-posting .tml pages, with Doc_Redirects to the
>>next page...
>>
>>
>
>I like this approach, I like .tml pages.
>
>
I do too..
>Handling state through Redirects is a pain though. Perhaps we should
>come up with a nicer abstraction to cover the messy details of building
>systems of DFSAs to represent interactions via templates.
>
>
Great idea!...Errr, WTF is a DFSA?
I have really gotten burned redirects and form variables with it this
time...
This project kinda went like this...
Are you sure you dont want a desktop app? No, it's a really simple app
they say, and the Web is good ;-)
We started with simple entry (submits)---o.k
Then "they" wanted to edit the stuff.. So now we had to populate the
pages w/ data read.(now we have logics like new record? old record? etc..)
We also had to read and overwrite the db with the edits.....
Then they wanted "sessions within a page", good case for mk's nested
views here...but correctly populating the pages w/ db reads became a chore..
Then they wanted to query the db, see all records, but be able to edit
only their own data....
And now they want to distribute the app at some point read-only ('bout
my only saving grace here... tclhttpd-startkit anyone?
>One facility you should become familiar with is [Httpd_Suspend] and
>[Httpd_Resume], which allows you to leave the connection open (for some
>period) while processing other incoming connections. It might be useful
>in this application.
>
>
I think in this case I would probably want the opposite; meaning I want
to complete my current mk transaction before moving on
to the next...
regards,
nicolas
|
|
From: Colin M. <co...@ch...> - 2004-10-07 14:19:48
|
On Fri, 2004-10-08 at 00:01, Nicolas Boretos wrote: > Colin McCormack wrote: > > >On Thu, 2004-10-07 at 19:14, Nicolas Boretos wrote: > > > > > > > >>As much as I > >>understand, "tclhttpd" is my "single user", and that > >>read/writes are sequential/serialized, the equivalent of opening a > >>console and playing with the mk db... > >> > >> > > > >That's a good way to look at it. > > > > > So, does this mean you feel that I should not have concurrency issues w/ > th mk? If you think of it as 'tclhttpd is my single user', then no you won't. > >>A few key points about the app. > >>1. A .tclaccess file permits access to the db > >Wrong place. Should be a .tml file (just dir/.tml is sourced in.) > I'm not sure I get it;-(...The .tclaccess file calls the browsers login > stuff...I'm not sure that a .tml file is designed for this > Or, am I mis-understanding you... Oh, I get it, you mean .tclaccess grants permission to access. I was confused between that and the other access. > >Handling state through Redirects is a pain though. Perhaps we should > >come up with a nicer abstraction to cover the messy details of building > >systems of DFSAs to represent interactions via templates. > Great idea!...Errr, WTF is a DFSA? > I have really gotten burned redirects and form variables with it this > time... Good idea for a project sometime. DFSA = Deterministic Finite State Automaton. State machine. > >One facility you should become familiar with is [Httpd_Suspend] and > >[Httpd_Resume], which allows you to leave the connection open (for some > >period) while processing other incoming connections. It might be useful > >in this application. > I think in this case I would probably want the opposite; meaning I want > to complete my current mk transaction before moving on > to the next... Yes, you want to serialise mk transactions, but you can't serialise web transactions ... they come in whenever someone initiates a connection. So you need to be able to put a web transaction on hold, pending the release of the mk lock. One way to do this, I think, is to place pending requests which are waiting on a lock into a queue, suspend the connection, and then restart one of them when the lock is released. A kind of poor-man's multitasking. Otherwise, when a new connection comes in, what're you going to do? Return an error page? -- Colin McCormack <co...@ch...> |
|
From: Nicolas B. <ni...@ma...> - 2004-10-07 14:50:43
|
Colin McCormack wrote: > > >Good idea for a project sometime. > >DFSA = Deterministic Finite State Automaton. State machine. > > > Wow... >>>One facility you should become familiar with is [Httpd_Suspend] and >>>[Httpd_Resume], which allows you to leave the connection open (for some >>>period) while processing other incoming connections. It might be useful >>>in this application. >>> >>> > > > >>I think in this case I would probably want the opposite; meaning I want >>to complete my current mk transaction before moving on >>to the next... >> >> > >Yes, you want to serialise mk transactions, but you can't serialise web >transactions ... they come in whenever someone initiates a connection. > >So you need to be able to put a web transaction on hold, pending the >release of the mk lock. One way to do this, I think, is to place >pending requests which are waiting on a lock into a queue, suspend the >connection, and then restart one of them when the lock is released. A >kind of poor-man's multitasking. > > Well, right now what I do is grab a record identifier (oid) from a counter when someone wants to add a record. The next person would grab the next oid... User fills in form and submits..at this point, I append to the mk db. Assuming someone else tries to appends at the same time, I would think tclhttpd would first complete the one of the appends and then move on to the next..Correct?? From then on, I just use the oid pointing to the table row to read/write from it. I dont delete rows live (which shifts rows and might confuse mk) >Otherwise, when a new connection comes in, what're you going to do? > If the server is busy (talking ms here, the users browser responds a little slower before it writes and re-directs...) > >Return an error page? > > got to go, let's resume this tommorrow.. nicolas |
|
From: Nicolas B. <ni...@ma...> - 2004-10-07 14:11:15
|
Hi Again
Is there any simple or built-in way in tclhttpd for checking your page
flow, meaning verify that you got to a page from another???
currently doing cludges like the following..
if {[string match "$::env(HTTP_REFERER)"
"http://$::env(HTTP_HOST)/rubia/parts.tml?record_id=[ncgi::value
record_id]&rec_id=[ncgi::value rec_id]&session_id=[ncgi::value
session_id]&use_name=[ncgi::value use_name]"]} {
rubia::populate_checkboxes month_collected [ncgi::value record_id]
month_collected session_id [ncgi::value session_id] use_name
[ncgi::value use_name]
rubia::populate_checkboxes month_traded [ncgi::value record_id] .blahhhhhh
Or how to check whether form is referred or self posted...??
proc rubia::is_self_posted {} {
if {$::env(REQUEST_URI) != "[eval join
{http://$::env(HTTP_HOST)$::page(url)}]"} {
####Form is refered, so lock record####
return 0
} else {
####Form is self-posted, write data etc
return 1
}
}
or the inverse...
proc rubia::is_referred {} {
if {$::env(HTTP_REFERER) != "[eval join
{http://$::env(HTTP_HOST)$::page(url)}]"} {
########
return 1
} else {
####Form is self-posted, write data etc
return 0
}
}
This used in the .tml pages to decide what action to take ...
if {[rubia::is_self_posted]} { do someting...
This gets painfull after a while...
regards,
nicolas
|
|
From: Colin M. <co...@ch...> - 2004-10-07 14:24:35
|
On Fri, 2004-10-08 at 00:09, Nicolas Boretos wrote:
> Is there any simple or built-in way in tclhttpd for checking your page
> flow, meaning verify that you got to a page from another???
Not that I know of, but it would be a cool project.
What you want (I think) is to drive each user's interaction from a state
machine. Their session starts in state 0, then depending on the inputs
they submit, it moves to a different state.
You define a FSM (aka DFSA) which determines which transitions are
legal.
There's a tcllib FSM package. Could be useful for this kind of thing.
> currently doing cludges like the following..
>
> if {[string match "$::env(HTTP_REFERER)"
> "http://$::env(HTTP_HOST)/rubia/parts.tml?record_id=[ncgi::value
> record_id]&rec_id=[ncgi::value rec_id]&session_id=[ncgi::value
> session_id]&use_name=[ncgi::value use_name]"]} {
> rubia::populate_checkboxes month_collected [ncgi::value record_id]
> month_collected session_id [ncgi::value session_id] use_name
> [ncgi::value use_name]
> rubia::populate_checkboxes month_traded [ncgi::value record_id] .blahhhhhh
>
> Or how to check whether form is referred or self posted...??
>
> proc rubia::is_self_posted {} {
> if {$::env(REQUEST_URI) != "[eval join
> {http://$::env(HTTP_HOST)$::page(url)}]"} {
> ####Form is refered, so lock record####
> return 0
> } else {
> ####Form is self-posted, write data etc
> return 1
> }
> }
>
> or the inverse...
>
> proc rubia::is_referred {} {
> if {$::env(HTTP_REFERER) != "[eval join
> {http://$::env(HTTP_HOST)$::page(url)}]"} {
> ########
> return 1
> } else {
> ####Form is self-posted, write data etc
> return 0
> }
> }
>
> This used in the .tml pages to decide what action to take ...
> if {[rubia::is_self_posted]} { do someting...
>
> This gets painfull after a while...
Word.
--
Colin McCormack <co...@ch...>
|
|
From: Michael S. <sc...@un...> - 2004-10-07 15:16:59
|
Colin McCormack schrieb: > On Fri, 2004-10-08 at 00:09, Nicolas Boretos wrote: > > >>Is there any simple or built-in way in tclhttpd for checking your page >>flow, meaning verify that you got to a page from another??? > > > Not that I know of, but it would be a cool project. > > What you want (I think) is to drive each user's interaction from a state > machine. Their session starts in state 0, then depending on the inputs > they submit, it moves to a different state. > > You define a FSM (aka DFSA) which determines which transitions are > legal. > > There's a tcllib FSM package. Could be useful for this kind of thing. Something like joining the FSM package with the session interpreters and adding some helpers to drive it? Michael |
|
From: Colin M. <co...@ch...> - 2004-10-07 15:53:40
|
On Fri, 2004-10-08 at 01:16, Michael Schlenker wrote: > Colin McCormack schrieb: > > On Fri, 2004-10-08 at 00:09, Nicolas Boretos wrote: > > > >>Is there any simple or built-in way in tclhttpd for checking your page > >>flow, meaning verify that you got to a page from another??? > > > > Not that I know of, but it would be a cool project. > > > > What you want (I think) is to drive each user's interaction from a state > > machine. Their session starts in state 0, then depending on the inputs > > they submit, it moves to a different state. > > > > You define a FSM (aka DFSA) which determines which transitions are > > legal. > > > > There's a tcllib FSM package. Could be useful for this kind of thing. > > Something like joining the FSM package with the session interpreters and > adding some helpers to drive it? Yes. I just looked at http://tcllib.sourceforge.net/doc/fa.html and http://tcllib.sourceforge.net/doc/dexec.html as a result of Nick's query, and it seems that it would be suitable. Something like this: You define a set of states (page names) and a set of transitions and symbols from state to state. One of the input variables from a form is named 'symbol' and the directory .tml checks that symbol represents a valid transition (by calling [$fa put $symbol] on an fa generated by [::grammar::fa::dexec] over your DFA.) One could also calculate something from form inputs and synthesise a symbol to put into $fa. If the transition isn't legal, $fa will call an error routine, so you can generate a redirect and reset the state to some known state. If the transition is terminal, you close the session, or the transaction. The only problem I can see with this model is knowing what state $fa is currently in, in case that matters ... one could always use a cookie or a session variable to track the state ... by for example recording the current page requested (assuming you'd named states for pages, which I think is a good idea.) If you felt energetic, you could even write a Tk GUI to specify the DFA. Anyway, (a) it would ensure that you couldn't end up in a state by following an illegal path, or in an uncontrolled manner; (b) programming by DFAs seems seductive, but it can very quickly become unwieldy; (c) often you need a single transition to some known state (for example, on input error you might want to restart the transaction) ... if you have a lot of these, you can nest DFAs - going into a state which means another DFA is handling input. I implemented ISO protocols (like X25) in the 80s with this stuff. -- Colin McCormack <co...@ch...> |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X