A lot of people seem confused by your architecture. It might help if you provided a complete (but high-level) description of the architecture of the system in a single email.
On Wed, May 16, 2012 at 12:47 PM, Eugène Ngontang <sympav...@gmail.com>wrote: > 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. > -- Marcin Tustin Tel: 07773 787 105 -- 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.
