No i'm not inventing a server. The application has a centrilzed server (module server installed on a dedicated host ). The dispatches tasks to remote clients (the client module is installed on each client host) and receives informations from clients about taks state.
How would you like me to describe or call my app components? What is not clear for you in my architecture description? How would you call my server module? And i'm not saying the database is installed on the same machine as the server, even if it could be. But only the server can access database directly. If you like so, What i call server could stand for a central task supervisor. Thanks for attention Jani. Le 16 mai 2012 12:01, "Jani Tiainen" <rede...@gmail.com> a écrit : > Hi, > > Like I said, it all depends what you have and what is the goal. > > You keep constantly talking about magical "server" that talks with the > database. Is this server already existing piece of infrastructure that some > programs already use and you like to hook up with that? > > Or is this server something that you just invented in lack of better > knowledge? > > You talk about state changes (in example you give a task). Must those > changes be reflected in "real time" between arbitrary clients? Or is it > sufficient that client sees changes at some later point? > > > > 16.5.2012 3:30, Eugène Ngontang kirjoitti: > >> Hi Jani! >> >> Now you can understand what i meant, but I'm not just try to mec things >> complicated. >> >> I'm not talking here about my technical implementation, but i'm >> describing the needs/contraints, and my app architecture to you. >> >> - The remote clients are at the heart of the software system, since >> data stored in the database are destined to them (the server push each >> information to the corresponding host) >> - When a client starts, it trys to establish a connection with the >> server, and if succeed, it retrieves its informations from the server. >> The server then send back informations conerning the host executing the >> client (the way server retrieves informations from the data base manager >> doesn't matter here, it's a technical purpose) >> - When a task state changes, it has to notify the server by sending a >> packet through the network. The GUI (web browser) has then to display >> the new state. >> - When a user of the software wants to create a new task on a host, it >> uses the GUI for the purpose, and the information has to be sent to the >> remote corresponding client/host for processing. >> >> Tell in my place, what logic would you adopt. I would like idea from you >> guys in this case, before go on a first definitive choice. >> >> I can see web sockets solves so much problems for developpers, and i'm >> still looking if it could help achieve correctly what I want to. The >> problem of IE < 10 for the instance is not so important. >> >> Now also, can you try to advise me the best way for serving file using >> python-Django (apache, unicorn, ..)? >> >> Thanks again. >> >> 2012/5/15 Jani Tiainen <rede...@gmail.com <mailto:rede...@gmail.com>> >> >> Hi, >> >> Now it starts to make "sense". >> >> I just wonder why are you trying to build something so extremely >> complicated? >> >> What is the rationale behind to have additional middleware layer >> between web ui and the server backend? >> >> Wouldn't it be sufficient to have architecture like: >> >> Browser <-> django middleware <-> remote backend >> >> Communication between django middle ware and remote backend should >> be built on top of some messaging system, like celery + rabbitmq >> which gives you quite standard asyncronous communication between >> django middleware and remote backend. Of course you might need to >> write some adapters on remote side but that's part of the job. >> >> Only real problem is that if you need to push changes to browser >> side. There doesn't exists any really good ways to do that. HTML5 >> was supposed to bring websockets to overcome the problem. One big >> problem is that only from IE series only IE 10 supports it. All >> others, FF, Chrome, Safari has had it for a good while. >> >> There exists also alternative workarounds like Comet, BOSH, push and >> few others. >> >> So let >> 15.5.2012 2:18, Eugčne Ngontang kirjoitti: >> >> Hi Jani! >> >> I haven't seen the last statements of your post, whre you say >> I'm not >> really clear and that i'm building a non-http GUI using Django. >> >> >> OK let's stay on the rendering issue only, and specify things >> simply. >> This is a simple description of the architecture I want to set up : >> >> - A Client (not a user interface). Client here means a module >> which is >> installed in a remote computer and communicate with the server >> via socket. >> >> - A server listening from several remote client (Here i'm not >> talking >> yet about http request), and receive informatons from them. In fact >> client must be doing actions and send informations about their >> actions >> to the server. In the oder hand data to be processed by each >> client is >> pushed/dispatched by the server. >> >> - And admin (not Django Admin, but admin in the sens of my app), >> destined to be the module allowing use of the application. Then the >> Admin module is part of the server and will proviede a GUI for >> manipulating data in the data base. It's in this GUI that users >> of the >> application will enter their request, by filling a form or >> clicking a >> link for exemple. And data from the GUI could be stored in the data >> base, while being send to the remote clients (not to be >> displayed by the >> client, but to be processed). In the same way, informations >> comming from >> those clients to the server have to be diplayed in the GUI. >> >> With a graphical GUI, The server could have a reference to an >> object >> representing my GUI, and it will be done. >> But I choose a web GUI for view and administration. It's where >> Django comes. >> >> And my problem is to make my server being running a network thread, >> receiving data from the GUI(web browser) and sending >> informations update >> to the GUI (for web page content). >> >> This is really my issue. If all the actions of my server >> depended on my >> GUI request (http request), I could do what I like behind when >> handling >> a http request, but while managing http:8080 connexions, the >> application >> is running another process/thread on another TCP/UDP port. >> >> And yes I want a web GUI. >> >> Is why I'm looking the best way to achieve that. We can exclude >> Django >> web server, as it will not be used in production for the >> application >> deployment. >> >> Hope now it's clear for you, and more for the other users. >> >> Thanks! >> >> 2012/5/13 Jani Tiainen <rede...@gmail.com >> <mailto:rede...@gmail.com> <mailto:rede...@gmail.com >> <mailto:rede...@gmail.com>>> >> >> >> Hi, >> >> There is several ways to achieve what you maybe want to do. >> One of >> the simplest way is separate frontend (your userinterface) and >> server backend. You can build your Django application as a >> service >> (xml-rpc, json-rpc, restful). That would give you advantage to >> choose whatever frontend you like. Of course it would add >> some overhead. >> >> On Sun, May 13, 2012 at 1:14 PM, Eugene NGONTANG >> <sympav...@gmail.com <mailto:sympav...@gmail.com> >> <mailto:sympav...@gmail.com <mailto:sympav...@gmail.com>>> wrote: >> >> Hi! >> >> I'm a python developper, but new in django. >> >> I'm devolopping a multi clients-server application. >> >> The server and the clients are communicating via >> sockets, The server >> receive somme states from clients, and display them in >> the User >> interface. >> In the other hand, the server has to send a >> message(packet) to the >> client when an event occurs in the GUI, and data are >> stored in a >> database. >> >> >> Note that Django is mainly built for web (HTTP protocol based) >> applications. In such an environment you run two different >> things: >> your GUI (usually browser) that is totally ignorant of >> server side >> (Django). Then you send request to some URL, Django routes it >> to >> some view and view produces again next output to be >> displayed in GUI >> (browser again). One of the common functions in the view is >> database >> manipulation. >> >> Then I choose to make a web interface where data could >> be viewed and >> manipulated. And I discovered Django, which fit all my >> needs. I >> tested >> and liked the framework. >> >> My questions are: >> - Can I override the djando admin methods so that i can >> not only >> customized my views and html page, but also manipulate >> objects in >> database, so that i can do another action when catching >> an event in >> the GUi. >> For example, taking the django admin tutorial, I would >> like to >> do and >> action like sending a message the user choose "add a >> poll". How >> can I >> do those things? Cause I noticed that method that alter >> data in data >> base are part of django admin module and cannot be >> overriden >> >> >> You shouldn't "fight against admin". If something cannot be >> done in >> the admin you usually get a way with writing your own stuff. >> >> - To achieve what I want, i would like to run my server >> engine >> and my >> django admin in two separated threads. How do i run my >> admin >> module in >> a thread? Cause till now i'm using the command line "python >> manage.py >> runserver >> >> >> Again your GUI would run "somewhere" (it's not relevant) and >> it's >> not concern of Django. It's architecture is designed to be >> share >> nothing - which means that you can run several >> threads/processes of >> your applications - And those threads/processes are not aware >> of >> other existence. And it doesn't matter. >> >> - I also tried to overide tables name, and foreign keys >> names. Could >> you guys provide me a true life example? >> >> >> Err.. Override what and where? And how you tried to do that? >> >> - And now in the production step, I would like you guys >> to tell me >> what to choose for serving files. I would like to with your >> experience >> what's better between running a unicorn server or apache >> with >> mod_wsgi >> >> I don't know if i'm clear, but i hope. In brief I'd like >> to use the >> django framework features to design my Gui like i want, >> customize >> interactions between the gui and the backend, and choose >> a good web >> server for the production. >> >> >> No you're definitely not clear. My interpretation is that >> you want >> to build (non-http based) GUI using Django as backend >> server. Even >> Django isn't exactly designed for such a work it still can >> do it. >> >> If it was something else try to split your questions in smaller >> fragments, perferably with more clearly specified use cases, >> workflows and samples of the code. >> >> Thank you for advance >> >> -- >> 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 <mailto:django-users@** >> googlegroups.com <django-users@googlegroups.com>> >> <mailto:django-users@__googleg**roups.com<http://googlegroups.com> >> <mailto:django-users@**googlegroups.com<django-users@googlegroups.com> >> >>. >> >> To unsubscribe from this group, send email to >> django-users+unsubscribe@__goo**glegroups.com<http://googlegroups.com> >> >> <mailto:django-users%**2bunsubscr...@googlegroups.com<django-users%252bunsubscr...@googlegroups.com> >> **> >> >> <mailto:django-users%__**2bunsubscr...@googlegroups.com<django-users%25__2bunsubscr...@googlegroups.com> >> >> <mailto:django-users%**252Bunsubscribe@googlegroups.**com<django-users%25252bunsubscr...@googlegroups.com> >> >__>. >> >> For more options, visit this group at >> >> http://groups.google.com/__**group/django-users?hl=en<http://groups.google.com/__group/django-users?hl=en> >> >> <http://groups.google.com/**group/django-users?hl=en<http://groups.google.com/group/django-users?hl=en> >> >. >> >> >> >> >> -- >> Jani Tiainen >> >> - Well planned is half done, and a half done has been >> sufficient >> before... >> >> -- >> 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 <mailto:django-users@** >> googlegroups.com <django-users@googlegroups.com>> >> <mailto:django-users@__googleg**roups.com<http://googlegroups.com> >> <mailto:django-users@**googlegroups.com<django-users@googlegroups.com> >> >>. >> >> To unsubscribe from this group, send email to >> django-users+unsubscribe@__goo**glegroups.com<http://googlegroups.com> >> >> <mailto:django-users%**2bunsubscr...@googlegroups.com<django-users%252bunsubscr...@googlegroups.com> >> **> >> >> <mailto:django-users%__**2bunsubscr...@googlegroups.com<django-users%25__2bunsubscr...@googlegroups.com> >> >> <mailto:django-users%**252Bunsubscribe@googlegroups.**com<django-users%25252bunsubscr...@googlegroups.com> >> >__>. >> >> For more options, visit this group at >> >> http://groups.google.com/__**group/django-users?hl=en<http://groups.google.com/__group/django-users?hl=en> >> >> <http://groups.google.com/**group/django-users?hl=en<http://groups.google.com/group/django-users?hl=en> >> >. >> >> >> >> >> -- >> ngont...@epitech.net <mailto:ngont...@epitech.net> >> <mailto:ngont...@epitech.net <mailto:ngont...@epitech.net>> >> sympav...@gmail.com <mailto:sympav...@gmail.com> >> <mailto:sympav...@gmail.com <mailto:sympav...@gmail.com>> >> ------------------------------**__----------------------------**-- >> /*Aux hommes il faut un chef, et au*//* chef il faut des hommes!*/ >> >> >> -- >> 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 >> <mailto:django-users@**googlegroups.com<django-users@googlegroups.com> >> >. >> To unsubscribe from this group, send email to >> django-users+unsubscribe@__goo**glegroups.com<http://googlegroups.com> >> >> <mailto:django-users%**2bunsubscr...@googlegroups.com<django-users%252bunsubscr...@googlegroups.com> >> **>. >> For more options, visit this group at >> >> http://groups.google.com/__**group/django-users?hl=en<http://groups.google.com/__group/django-users?hl=en> >> >> <http://groups.google.com/**group/django-users?hl=en<http://groups.google.com/group/django-users?hl=en> >> >. >> >> >> >> -- >> Jani Tiainen >> >> - Well planned is half done and a half done has been sufficient >> before... >> >> >> -- >> 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 >> <mailto:django-users@**googlegroups.com<django-users@googlegroups.com> >> >. >> To unsubscribe from this group, send email to >> django-users+unsubscribe@__goo**glegroups.com<http://googlegroups.com> >> >> <mailto:django-users%**2bunsubscr...@googlegroups.com<django-users%252bunsubscr...@googlegroups.com> >> **>. >> For more options, visit this group at >> >> http://groups.google.com/__**group/django-users?hl=en<http://groups.google.com/__group/django-users?hl=en> >> >> <http://groups.google.com/**group/django-users?hl=en<http://groups.google.com/group/django-users?hl=en> >> >. >> >> >> >> >> -- >> ngont...@epitech.net <mailto:ngont...@epitech.net> >> sympav...@gmail.com <mailto:sympav...@gmail.com> >> ------------------------------**------------------------------ >> /*Aux hommes il faut un chef, et au*//* chef il faut des hommes!*/ >> >> -- >> 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 >> django-users+unsubscribe@**googlegroups.com<django-users%2bunsubscr...@googlegroups.com> >> . >> For more options, visit this group at >> http://groups.google.com/**group/django-users?hl=en<http://groups.google.com/group/django-users?hl=en> >> . >> > > > -- > Jani Tiainen > > - Well planned is half done and a half done has been sufficient before... > > -- > 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 django-users+unsubscribe@** > googlegroups.com <django-users%2bunsubscr...@googlegroups.com>. > For more options, visit this group at http://groups.google.com/** > group/django-users?hl=en<http://groups.google.com/group/django-users?hl=en> > . > > -- 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 django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
