On Thursday, December 29, 2016 at 6:00:03 AM UTC-5, Andrew Godwin wrote:
A) My primary purpose for the django-channels to remote system is working great. I can download from a model and upload to a model through websockets (just for reference: the interface at the remote system is a C++ compiled application (w/ websockets) connected to a C# final product).
There are various need, by this example can best describe a single feature:
1) We have a debugging system on the remote system that will upload transactions from there to our Django model through websockets.
2) In that debugging system, we can set various levels of verbosity to control how much detail is returned.
3) I have a working Django web page now that can send commands that change the debugging level through a websocket-routed command in a JSON message with a particular debugging level (like 1-7). This web page uses a Django template with a radio button form for the 1-7 choices.
4) When a choice is changed on the form, Javascript catches it and calls a Django function that send the websocket command to the remote system to change the debugging (we track websocket instances of channel names in a database, so I can always contact a particular remote system by knowing our own internally-assign db id to lookup the Django channel name for that websocket connection).
In the above example, what I am looking for is that when the web page is initially rendered (url'd in browser), fetch the current debugging level from the remote system and pre-set the radio buttons. Right now of course, the page just renders with a default layout of the radio button without reference to what the current debugging level actually is at the remote site.
In addition to the websocket JSON command to tell the remote system to set a particular debugging level, I also have a command that requests the current debugging level. It's connecting the reply back data from that request command to the webpage when it's initially rendered that is proving difficult to understand.
Thanks for any help you or anyone can provide. I'm dealing with a lot of technologies and a lot of languages that I'm not totally expert or experienced with, but I will complete this project in one form or another. My system engineering background leads me to want a design that is more push and event-driven, than pull and polling. I can find a solution that is pull and polling (store in table, Javascript timed refresh from table), but I find the lack of immediacy of results and slushiness of current data with that strategy to be less than ideal.
-- Q) Are the websocket and the AJAX calls going to different clients/pages entirely, rather than them both being in the same page context? It sounds like the websocket is going to a server somewhere that's allocating resources and not going to a webpage/browser at all.
A) Currently the websockets are used in a background system running on Django and most of the use for websockets on this service are so the remote system we are interfacing with can pull a list of subscribers from a Django model and then the remote system does uncoordinated stuff with that. Occasionally, the remote system updates data to Django models for debugging information or sending statistics back.
In the normal course of the application, the web server web page interface is between user and Django model and has no need for a direct connection to the remote system through websockets; they are just setting up subscription types as a seller or buying subscriptions as a buyer. Later, when they are using the remote system, which happens with a completely different client native compiled application, not Django or web interface, they make use of the real purpose of our system which is enhanced by the subscriptions we sell. Basically, we
are using the Django web service to sell subscriptions which are then periodically download through websockets to a remote native compiled application.
On Thursday, December 29, 2016 at 6:00:03 AM UTC-5, Andrew Godwin wrote:
In the normal course of the application, the web server web page interface is between user and Django model and has no need for a direct connection to the remote system through websockets; they are just setting up subscription types as a seller or buying subscriptions as a buyer. Later, when they are using the remote system, which happens with a completely different client native compiled application, not Django or web interface, they make use of the real purpose of our system which is enhanced by the subscriptions we sell. Basically, we
are using the Django web service to sell subscriptions which are then periodically download through websockets to a remote native compiled application.
On Thursday, December 29, 2016 at 6:00:03 AM UTC-5, Andrew Godwin wrote:
Q) - Could it potentially take the websocket client that is sending the LOBBY data back that needs to then be conveyed over AJAX some time to reply? Say, more than ten seconds?
A) The return replies are just about instantaneous and very small in size. Although ultimately the system will interface with potentially 1000's of distinct remote systems, the Django web service is only used for a very, very short period of time by a user, and then maybe never again if they just continue to renew their subscription. The users are at the remote systems. We just sell stuff that makes that experience better. The need for displaying return data as envisioned in my original question is a rare occurannce almost exclusively used by sellers and more so, just by administrators of the system.
On Thursday, December 29, 2016 at 6:00:03 AM UTC-5, Andrew Godwin wrote:
On Thursday, December 29, 2016 at 6:00:03 AM UTC-5, Andrew Godwin wrote:
Q) I think I have an idea of what you're trying to do here and how to solve it, but I just need to be a bit more clear on the architecture first.
A) My primary purpose for the django-channels to remote system is working great. I can download from a model and upload to a model through websockets (just for reference: the interface at the remote system is a C++ compiled application (w/ websockets) connected to a C# final product).
There are various need, by this example can best describe a single feature:
1) We have a debugging system on the remote system that will upload transactions from there to our Django model through websockets.
2) In that debugging system, we can set various levels of verbosity to control how much detail is returned.
3) I have a working Django web page now that can send commands that change the debugging level through a websocket-routed command in a JSON message with a particular debugging level (like 1-7). This web page uses a Django template with a radio button form for the 1-7 choices.
4) When a choice is changed on the form, Javascript catches it and calls a Django function that send the websocket command to the remote system to change the debugging (we track websocket instances of channel names in a database, so I can always contact a particular remote system by knowing our own internally-assign db id to lookup the Django channel name for that websocket connection).
In the above example, what I am looking for is that when the web page is initially rendered (url'd in browser), fetch the current debugging level from the remote system and pre-set the radio buttons. Right now of course, the page just renders with a default layout of the radio button without reference to what the current debugging level actually is at the remote site.
In addition to the websocket JSON command to tell the remote system to set a particular debugging level, I also have a command that requests the current debugging level. It's connecting the reply back data from that request command to the webpage when it's initially rendered that is proving difficult to understand.
Thanks for any help you or anyone can provide. I'm dealing with a lot of technologies and a lot of languages that I'm not totally expert or experienced with, but I will complete this project in one form or another. My system engineering background leads me to want a design that is more push and event-driven, than pull and polling. I can find a solution that is pull and polling (store in table, Javascript timed refresh from table), but I find the lack of immediacy of results and slushiness of current data with that strategy to be less than ideal.
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+unsubscribe@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/df5d9d35-ac42-4e74-b948-23d4e9badb52%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
No comments:
Post a Comment