Session support

[SlavaSh]

Is it any way to use session (django) on browsers without cookie
support ?


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Session support

[RajeshD]

On Mar 27, 11:00 am, "SlavaSh" <[EMAIL PROTECTED]> wrote:
> Is it any way to use session (django) on browsers without cookie
> support ?

No. See the following for why not:

http://www.djangoproject.com/documentation/sessions/#session-ids-in-urls


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Session support

[SlavaSh]

This is wrong "intentional design decision".
There few more web clients in the world besides the IE and Firefox.
Part of them does not support cookies.

On 27 мар, 22:26, "RajeshD" <[EMAIL PROTECTED]> wrote:
> On Mar 27, 11:00 am, "SlavaSh" <[EMAIL PROTECTED]> wrote:
>
> > Is it any way to use session (django) on browsers without cookie
> > support ?
>
> No. See the following for why not:
>
> http://www.djangoproject.com/documentation/sessions/#session-ids-in-urls


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Session support

[James Bennett]

On 4/18/07, SlavaSh <[EMAIL PROTECTED]> wrote:
> This is wrong "intentional design decision".
> There few more web clients in the world besides the IE and Firefox.
> Part of them does not support cookies.

Django provides a sessions framework in 'django.contrib.sessions'
(note the "contrib" in that path) as a convenience for the common case
of needing to persist state across multiple HTTP requests. The common
case involves a user-agent which is capable of handling cookies --
around 90% of all web clients have cookies enabled, and the percentage
which does not tends to include fairly specific demographics and so
are not a problem for most sites

For the uncommon case, it would be possible for you to write your own
wrapper around the sessions framework which uses some other mechanism,
but I think this is a case where we simply will not be able to please
everyone with what Django ships by default, so we need to stick to
meeting the needs of the common case.

-- 
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Session support

[Honza Král]

On 4/18/07, James Bennett <[EMAIL PROTECTED]> wrote:
>
> On 4/18/07, SlavaSh <[EMAIL PROTECTED]> wrote:
> > This is wrong "intentional design decision".
> > There few more web clients in the world besides the IE and Firefox.
> > Part of them does not support cookies.
>
> Django provides a sessions framework in 'django.contrib.sessions'
> (note the "contrib" in that path) as a convenience for the common case
> of needing to persist state across multiple HTTP requests. The common
> case involves a user-agent which is capable of handling cookies --
> around 90% of all web clients have cookies enabled, and the percentage
> which does not tends to include fairly specific demographics and so
> are not a problem for most sites
>
> For the uncommon case, it would be possible for you to write your own
> wrapper around the sessions framework which uses some other mechanism,
> but I think this is a case where we simply will not be able to please
> everyone with what Django ships by default, so we need to stick to
> meeting the needs of the common case.

besides:

wc -l *
   0 __init__.py
 103 middleware.py
  88 models.py
 191 total

its just a few lines of code, just write your own middleware that will
handle session_id's in URL. You can still use the API and the models
from django.contrib.sessions...

>
> --
> "Bureaucrat Conrad, you are technically correct -- the best kind of correct."
>
> >
>


-- 
Honza Kr�l
E-Mail: [EMAIL PROTECTED]
ICQ#:   107471613
Phone:  +420 606 678585

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Implementing multiple session support in a chatbot

[Parth Sharma]

I am currently implementing a Chatbot purely in python.

In my current implementation, each time the user starts a new chat from a 
session, another Chatbot instance is launched and hence the Chatbot starts 
from the initial state.

I wish to change that behaviour and make it similar to let’s say chat on 
Facebook/Messenger, in which you can seamlessly move between sessions while 
having a chat without inconsistencies. Namely, I want these attributes:

   1. If the user enters anything from let’s say session A it should be 
   immediately visible in all ongoing sessions. Similarly, the Chatbot reply 
   should be visible in all the devices immediately.
   2. Have all sessions show the same chat history

To implement the first point, I used this example 
 from the 
django-channels docs and modified it by creating a single group/chatroom 
for each user. All the sessions from the same user get connected to the 
same group/chatroom and hence receive all the messages in the 
group/chatroom regardless of where they were sent from.

However, this implementation currently has a bug. Each time that a user is 
connected, it initializes a Chatbot instance which starts from the initial 
state again while the older connections have Chatbot instances that are 
currently at a different state.

This leads to inconsistent replies which are different based on which 
window the user typed something in.

Basically instead of having two sessions talk to the same Chatbot instance, 
we have two sessions talking to two different Chatbot instances and 
messages from all these four sources are getting added to the same chatroom.

Moreover, we are wasting resources by keeping multiple Chatbot instances 
per user which increases with the number of currently active sessions.

I want all of the user windows to interact with the same Chatbot instance. 
What would be the best way to implement that?

Currently I can think of three solutions:

   1. Creating another Django project the Chatbot and make requests to that 
   HTTP server. The Chatbot state is maintained in that server and any request 
   from the user will go to the same Chatbot instance.
  - This is straightforward to implement for me (simply spin up another 
  server)
  - This naturally solves all the problems regarding state as all the 
  instances will query the same Chatbot object
   2. Creating a *Master* channel thread which will hold the actual Chatbot 
   instance(a python object) and any new channels will will defer to it for 
   the reply from the Chatbot.
  - This will be complicated to implement
  - I will have to maintain which thread is master and which ones are 
  slaves
  - In situations where a user closes the master thread connection I 
  will somehow have to change one of the slave connections to a master 
  connection and pass the entire object(?!) or atleast pass the state 
  variable and re-create the chatbot instance.
   3. Spawn an independent thread/process in python for the chatbot 
   instance and have all the channel connections talk to that thread/process .
  - This will be hard for me to implement as I don’t currently know how 
  to do IPC in python
   
Are there any other solutions possible? What would be the ideal solution?

I am using the following technologies:

   1. Django  as the main backend, with Django 
   Channels  for WebSockets
   2. RASA NLU  for the NLU component of the 
   chatbot and a finite state machine model implemented using pytransitions 
    for the dialog management 
   in python

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/463657a5-588d-475d-940d-4d7ec0c708d4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Implementing multiple session support in a chatbot

[Chetan Ganji]

What you need is to implement 2 design patterns in your django app. Which
ones?

1. *Singleton* Design Pattern for the Chatbot. All the users and all of
their sessions are using the same chatbot instance.

Why?

Because when a new session is created for a user, he will be referring to
the same chatbot instance and all of previous history would be accessible.
You need to add a timestamp to each message. So that when a new session is
created,
all of previous messages can be to sent to this session by filtering on the
timestamp of the messages.

This instance can be used to store all of the sessions of all of the users.
Something like below.
That way when the observer getters and setters are called, they get a list
of active session of the current user.
So the actual message is sent by iterating over the active sessions. Hence
all the sessions get the same message.


class Chatbot(object):

_sessions = {
"username1": {
"mobile": [],
"desktop": []
},

"username2": {
"mobile": [],
"desktop": []
}

}

@classmethod
def get_sessions(self, username):
return self._sessions[username]


Other way to achieve singleton effect is create a instance of the chatbot
and import it wherever it is required.
This will given the same effect as singleton but without implementing it.


nikola = Chatbot()


Now just import nikola everywhere it is required.


2. *Observer* Design Pattern for the syncing of the messages across
multiple sessions.

Why?

Because, you need the chatbot to sync between multiple sessions. Same
message needs to goto multiple recipients.
When a new session is created, you will have to send the previous messages
to this new session.
This is the sole purpose of this design pattern. It's use is already
explained above.

As you are using django channels for websockets, you will have to combine
that code with this pattern.
I don't have any experience with websockets, you will have to figure it out
:P

I hope it helps :)


Regards,
Chetan Ganji
+91-900-483-4183
ganji.che...@gmail.com
http://ryucoder.in


On Sat, May 18, 2019 at 7:17 PM Parth Sharma 
wrote:

> I am currently implementing a Chatbot purely in python.
>
> In my current implementation, each time the user starts a new chat from a
> session, another Chatbot instance is launched and hence the Chatbot starts
> from the initial state.
>
> I wish to change that behaviour and make it similar to let’s say chat on
> Facebook/Messenger, in which you can seamlessly move between sessions while
> having a chat without inconsistencies. Namely, I want these attributes:
>
>1. If the user enters anything from let’s say session A it should be
>immediately visible in all ongoing sessions. Similarly, the Chatbot reply
>should be visible in all the devices immediately.
>2. Have all sessions show the same chat history
>
> To implement the first point, I used this example
>  from the
> django-channels docs and modified it by creating a single group/chatroom
> for each user. All the sessions from the same user get connected to the
> same group/chatroom and hence receive all the messages in the
> group/chatroom regardless of where they were sent from.
>
> However, this implementation currently has a bug. Each time that a user is
> connected, it initializes a Chatbot instance which starts from the initial
> state again while the older connections have Chatbot instances that are
> currently at a different state.
>
> This leads to inconsistent replies which are different based on which
> window the user typed something in.
>
> Basically instead of having two sessions talk to the same Chatbot
> instance, we have two sessions talking to two different Chatbot instances
> and messages from all these four sources are getting added to the same
> chatroom.
>
> Moreover, we are wasting resources by keeping multiple Chatbot instances
> per user which increases with the number of currently active sessions.
>
> I want all of the user windows to interact with the same Chatbot instance.
> What would be the best way to implement that?
>
> Currently I can think of three solutions:
>
>1. Creating another Django project the Chatbot and make requests to
>that HTTP server. The Chatbot state is maintained in that server and any
>request from the user will go to the same Chatbot instance.
>   - This is straightforward to implement for me (simply spin up
>   another server)
>   - This naturally solves all the problems regarding state as all the
>   instances will query the same Chatbot object
>2. Creating a *Master* channel thread which will hold the actual
>Chatbot instance(a python object) and any new channels will will defer to
>it for the reply from the Chatbot.
>   - This will be complicated to implement
>   - I will have to maintain which thread is master and which ones are
>   slaves
>   - In situations where a user closes the master thread connection I
>   

Re: Implementing multiple session support in a chatbot

[Parth Sharma]

Thanks a lot for your reply !

In the first part of your reply. I didn't really understand where exactly 
would I actually use this 
nikola = Chatbot()
and in which files would I import it? Can you please elaborate on the 
second solution a bit? 

On Sunday, 19 May 2019 02:59:30 UTC+5:30, Chetan Ganji wrote:
>
> What you need is to implement 2 design patterns in your django app. Which 
> ones?
>
> 1. *Singleton* Design Pattern for the Chatbot. All the users and all of 
> their sessions are using the same chatbot instance.
>
> Why?
>
> Because when a new session is created for a user, he will be referring to 
> the same chatbot instance and all of previous history would be accessible.
> You need to add a timestamp to each message. So that when a new session is 
> created,
> all of previous messages can be to sent to this session by filtering on 
> the timestamp of the messages.
>
> This instance can be used to store all of the sessions of all of the 
> users. Something like below.
> That way when the observer getters and setters are called, they get a list 
> of active session of the current user. 
> So the actual message is sent by iterating over the active sessions. Hence 
> all the sessions get the same message.
>
>
> class Chatbot(object):
>
> _sessions = {
> "username1": {
> "mobile": [],
> "desktop": []
> },
>
> "username2": {
> "mobile": [],
> "desktop": []
> }
>
> }
>
> @classmethod
> def get_sessions(self, username):
> return self._sessions[username]
>
>
> Other way to achieve singleton effect is create a instance of the chatbot 
> and import it wherever it is required. 
> This will given the same effect as singleton but without implementing it.
>
>
> nikola = Chatbot()
>
>
> Now just import nikola everywhere it is required.
>
>  
> 2. *Observer* Design Pattern for the syncing of the messages across 
> multiple sessions.
>
> Why?
>
> Because, you need the chatbot to sync between multiple sessions. Same 
> message needs to goto multiple recipients.
> When a new session is created, you will have to send the previous messages 
> to this new session.
> This is the sole purpose of this design pattern. It's use is already 
> explained above.
>
> As you are using django channels for websockets, you will have to combine 
> that code with this pattern.
> I don't have any experience with websockets, you will have to figure it 
> out :P 
>
> I hope it helps :) 
>  
>
> Regards,
> Chetan Ganji
> +91-900-483-4183
> ganji...@gmail.com 
> http://ryucoder.in
>
>
> On Sat, May 18, 2019 at 7:17 PM Parth Sharma  > wrote:
>
>> I am currently implementing a Chatbot purely in python.
>>
>> In my current implementation, each time the user starts a new chat from a 
>> session, another Chatbot instance is launched and hence the Chatbot starts 
>> from the initial state.
>>
>> I wish to change that behaviour and make it similar to let’s say chat on 
>> Facebook/Messenger, in which you can seamlessly move between sessions while 
>> having a chat without inconsistencies. Namely, I want these attributes:
>>
>>1. If the user enters anything from let’s say session A it should be 
>>immediately visible in all ongoing sessions. Similarly, the Chatbot reply 
>>should be visible in all the devices immediately.
>>2. Have all sessions show the same chat history
>>
>> To implement the first point, I used this example 
>>  from 
>> the django-channels docs and modified it by creating a single 
>> group/chatroom for each user. All the sessions from the same user get 
>> connected to the same group/chatroom and hence receive all the messages in 
>> the group/chatroom regardless of where they were sent from.
>>
>> However, this implementation currently has a bug. Each time that a user 
>> is connected, it initializes a Chatbot instance which starts from the 
>> initial state again while the older connections have Chatbot instances that 
>> are currently at a different state.
>>
>> This leads to inconsistent replies which are different based on which 
>> window the user typed something in.
>>
>> Basically instead of having two sessions talk to the same Chatbot 
>> instance, we have two sessions talking to two different Chatbot instances 
>> and messages from all these four sources are getting added to the same 
>> chatroom.
>>
>> Moreover, we are wasting resources by keeping multiple Chatbot instances 
>> per user which increases with the number of currently active sessions.
>>
>> I want all of the user windows to interact with the same Chatbot 
>> instance. What would be the best way to implement that?
>>
>> Currently I can think of three solutions:
>>
>>1. Creating another Django project the Chatbot and make requests to 
>>that HTTP server. The Chatbot state is maintained in that server and any 
>>request from the user will go to the same Chatbot instance.
>>   - This is straightforward to implement for me (simply spin up 
>>   another serv

Re: Implementing multiple session support in a chatbot

[Chetan Ganji]

Hi Parth,

There is only one solution. It has two parts in which you will implement 2
design patterns for the chatbot.
*Singleton* and *Observer*.

RE : Where would you use it?
nikola = Chatbot() # it is called instantiating the chatbot

Wherever it is required :P

The idea is to create one and only one instance of the chatbot for the
whole project and make it available when the projects get loaded into the
memory. Two of the best ways to do this is -

   1. Instantiate the chatbot in the *wsgi.py* file of the project. From
   this file, import it and use as required.
   2. Instantiate the chatbot in the *settings.py* file of the project.
   That way you could import it wherever it is required and access it as
   *settings.nikola*.

   from django.conf import settings



RE : in which files would I import it?

Wherever it is required :P

Lets say, there is a view which will return a response. Its a fictional
example, take it with grain and salt :P

from django.conf import settings
from django.http import JsonResponse

def Reply(request, message):

sessions = settings.nikola.get_sessions(request.user.username)
response = settings.nikola.choose_response(message)

# send the message to all the remaining sessions, except the current one
# as the current session would get this reply in the response of this view
settings.nikola.send_session_replies(sessions)

return JsonResponse(data=response)


I hope its clear now :)


Regards,
Chetan Ganji
+91-900-483-4183
ganji.che...@gmail.com
http://ryucoder.in



I’m
protected online with Avast Free Antivirus. Get it here — it’s free forever.

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Mon, May 20, 2019 at 2:49 AM Parth Sharma 
wrote:

> Thanks a lot for your reply !
>
> In the first part of your reply. I didn't really understand where exactly
> would I actually use this
> nikola = Chatbot()
> and in which files would I import it? Can you please elaborate on the
> second solution a bit?
>
> On Sunday, 19 May 2019 02:59:30 UTC+5:30, Chetan Ganji wrote:
>>
>> What you need is to implement 2 design patterns in your django app. Which
>> ones?
>>
>> 1. *Singleton* Design Pattern for the Chatbot. All the users and all of
>> their sessions are using the same chatbot instance.
>>
>> Why?
>>
>> Because when a new session is created for a user, he will be referring to
>> the same chatbot instance and all of previous history would be accessible.
>> You need to add a timestamp to each message. So that when a new session
>> is created,
>> all of previous messages can be to sent to this session by filtering on
>> the timestamp of the messages.
>>
>> This instance can be used to store all of the sessions of all of the
>> users. Something like below.
>> That way when the observer getters and setters are called, they get a
>> list of active session of the current user.
>> So the actual message is sent by iterating over the active sessions.
>> Hence all the sessions get the same message.
>>
>>
>> class Chatbot(object):
>>
>> _sessions = {
>> "username1": {
>> "mobile": [],
>> "desktop": []
>> },
>>
>> "username2": {
>> "mobile": [],
>> "desktop": []
>> }
>>
>> }
>>
>> @classmethod
>> def get_sessions(self, username):
>> return self._sessions[username]
>>
>>
>> Other way to achieve singleton effect is create a instance of the chatbot
>> and import it wherever it is required.
>> This will given the same effect as singleton but without implementing it.
>>
>>
>> nikola = Chatbot()
>>
>>
>> Now just import nikola everywhere it is required.
>>
>>
>> 2. *Observer* Design Pattern for the syncing of the messages across
>> multiple sessions.
>>
>> Why?
>>
>> Because, you need the chatbot to sync between multiple sessions. Same
>> message needs to goto multiple recipients.
>> When a new session is created, you will have to send the previous
>> messages to this new session.
>> This is the sole purpose of this design pattern. It's use is already
>> explained above.
>>
>> As you are using django channels for websockets, you will have to combine
>> that code with this pattern.
>> I don't have any experience with websockets, you will have to figure it
>> out :P
>>
>> I hope it helps :)
>>
>>
>> Regards,
>> Chetan Ganji
>> +91-900-483-4183
>> ganji...@gmail.com
>> http://ryucoder.in
>>
>>
>> On Sat, May 18, 2019 at 7:17 PM Parth Sharma 
>> wrote:
>>
>>> I am currently implementing a Chatbot purely in python.
>>>
>>> In my current implementation, each time the user starts a new chat from
>>> a session, another Chatbot instance is launched and hence the Chatbot
>>> starts from the initial state.
>>>
>>> I wish to change that behaviour and make it similar to let’s sa