Regular expression code implementation review between Tcl vs Python

[K_Lee]

Ralf Fassel <ralfixx at gmx.de> wrote in message news:<yga65hqn9v6.fsf at jupiter.akutech-local.de>...
> * Google_Post at slink-software.com (K_Lee)
> | http://www.slink-software.com/W/SrcDoc_Top/tcl8.4.4/tcl8.4.4.sdoc/N_92
> 
> <quote>
>     If you still like to use this webbase application, please enable
>     the cookie in your browser and try again.
> </quote>
> 
> You bet I won't.  If you want people to read your stuff, let them read
> it with no obstacles.
> 
> R'
Sorry about that.

Will work on that.  Here's the reason why we need the cookie at
this point.   

The SDoc is a web document (like blogging ) where any number
of users (current we have ~800 users at our website) can write and
read
any topics in the document.   The topics are organized like 
a directory tree.   Each users can collaps and expand his/her owner
topics without changing the view of other users.

For example, we have a lots internal webbase document with 
thousand of topics. 

But at any this moment for the TCL document, I really
only care about regex but not the network subtree.  My current view
have the network part is collaps state and the regular expression is 
is full expand state.

We use cookie to keep track of each topics state in every document
for every user not to keep track of what they view but to help
minimize
the overload of information when the topic tree is shown.


I really didn't want to implement that features with cookie initially,
but I had tough time finding other "right"  method to do it.  Now I
believe
we can implement it with the embedded the user id as part of URL or 
?uid=12345 append at the end of every URL. 

This will allows user who turn off cookie to browse the page.  But if
the
reason for turnning off the cookie is so the website can't track you.
It doesn't really solve the problem.  

Either way, any dynamically generated webpage can still track you with
the id embedded into the URL in every reponse even when you turn off
the cookie.

BTW, I see a lot of more other info from the weblog that is far more 
interesting than cookies.   Cookie are kind boring from analyzing the 
webtraffic point of view.   


Sorry again for the "obstacles".  

:-) 

K_Lee