| chat.freenode.net #tryton log beginning Tue Sep 18 00:00:02 CEST 2012 | ||
| 2012-09-18 11:43 -!- tflorac(5bcfb0c6@gateway/web/freenode/ip.91.207.176.198) has left #tryton | ||
| 2012-09-18 13:31 -!- vegai(~vegai@archlinux/developer/vegai) has left #tryton | ||
| 2012-09-18 18:03 <adeb6600> is there a defined way for event management in tryton? im looking at multiple access to trytond from different location how does trytond sycronises all these events | ||
| 2012-09-18 18:05 <nicoe> adeb6600: I don't understand | ||
| 2012-09-18 18:05 <nicoe> adeb6600: What ar you trying to do | ||
| 2012-09-18 18:16 <juanfe> adeb6600 I know that trytond can manage it as a transaction, see in http://code.google.com/p/tryton/wiki/HowToUseTrytondAsAModule | ||
| 2012-09-18 18:25 <adeb6600> nicoe: consider me a newbie my line of thought is trytond responds to json-rpc calls from the client. my question is more like can trytond update multiple clients of the changes made by one client? | ||
| 2012-09-18 18:25 <cedk> adeb6600: please provide a usecase | ||
| 2012-09-18 18:28 <bechamel> adeb6600: the server works like a web-server, it does not push info to the client. | ||
| 2012-09-18 18:32 <adeb6600> bechamel: that answers my question if trytond does not push information to client then it cannot update multiple clients of updates/changes made by one client | ||
| 2012-09-18 18:36 <cedk> adeb6600: we use a optimistic locking system to prevent conflict | ||
| 2012-09-18 18:36 <cedk> adeb6600: it is enough for most of the usage | ||
| 2012-09-18 18:36 <cedk> adeb6600: what is yours? | ||
| 2012-09-18 18:44 <adeb6600> Cedk: im considering tryton as the platform for an hotel management system network covering over 1000 small hotels ... thats my scenario | ||
| 2012-09-18 18:45 <cedk> adeb6600: and where do you need pushing? | ||
| 2012-09-18 18:45 <bechamel> adeb6600: and you want to inform users when a room has been reserved ? | ||
| 2012-09-18 18:47 <adeb6600> Yes much more there is a central organisation that effectively pushes data to each of these organisations | ||
| 2012-09-18 18:48 <adeb6600> cedk: a monitoring organisation pushes data to each of these hotels | ||
| 2012-09-18 18:49 <bechamel> adeb6600: and each kind of info needs to be pushed in realtime ? | ||
| 2012-09-18 18:49 <cedk> adeb6600: don't understand, Tryton is one database central | ||
| 2012-09-18 18:50 <adeb6600> bechamel:yes | ||
| 2012-09-18 18:52 <bechamel> adeb6600: sorry, I made a typo, my question was: _which_ kind of info need to be pushed ? | ||
| 2012-09-18 18:53 <adeb6600> cedk: yes i know tryton is one database central. a better scenario will using tryton as the backend erp of an online store with the need for purchase request on the web store to be pushed realtime to the backend | ||
| 2012-09-18 18:54 <bechamel> adeb6600: but maybe you are talking about a federation of server: each hotel as one server whith his own data, and then there is a central sever that provide data that must be synced with the hotel servers | ||
| 2012-09-18 18:55 <cedk> adeb6600: so has to be pushed? | ||
| 2012-09-18 18:56 <bechamel> adeb6600: this is a common scenario, if the frontend call the tryton sever, it's a standart client-server behaviour | ||
| 2012-09-18 18:56 <adeb6600> bechamel : exactly thats the perfect scenario | ||
| 2012-09-18 18:59 <cedk> so no question :-) | ||
| 2012-09-18 19:03 <adeb6600> bechamel:the frontend does not call the central server | ||
| 2012-09-18 19:04 <adeb6600> bechamel: at least not directly | ||
| 2012-09-18 19:09 <cedk> adeb6600: why? | ||
| 2012-09-18 19:12 <adeb6600> cedk: because the central server(entity) is not an hotel it is a monitoring entity | ||
| 2012-09-18 19:14 <cedk> adeb6600: and why this is preventing to connect to it? | ||
| 2012-09-18 19:26 <katr> cedk: Hi! | ||
| 2012-09-18 19:27 <cedk> katr: hi | ||
| 2012-09-18 19:27 <katr> cedk: Regarding your comment about account_dunning: When I started writing the module I did not consider releasing it to the public. But as dunning is something really common, I thought maybe it would be useful for someone else. | ||
| 2012-09-18 19:28 <katr> The usecase is quite simple: A customer does not pay an overdue receivable entry. | ||
| 2012-09-18 19:28 <cedk> katr: yes I understand the use case, but it is about how to solve it | ||
| 2012-09-18 19:29 <katr> You have to remind him to do so. Further more (but this would go to some other module in the future maybe), you will remind him and charge dunning fees. | ||
| 2012-09-18 19:30 <katr> cedk: The code is only 300 SLOC and contains a lot of boiler plate stuff, so I'm open to any discussion. | ||
| 2012-09-18 19:31 <katr> I'm not yet in production use with that module. | ||
| 2012-09-18 19:33 <cedk> katr: first step is to agree on a design | ||
| 2012-09-18 19:33 <cedk> katr: if you want to have such agreement, you have to provide a blueprint about it | ||
| 2012-09-18 19:35 <katr> cedk: Sorry, I'll have to leave for a moment. Will be back later. | ||
| 2012-09-18 19:35 <cedk> katr: also I'm particulary concern about it because you said you took it from OpenERP | ||
| 2012-09-18 19:36 <cedk> also I think it is not a so easy task as it could look | ||
| 2012-09-18 21:08 <katr> cedk: Just to get the record straight: I did not copy one single line from Open ERP. | ||
| 2012-09-18 21:09 <katr> cedk: Basically I only see two possible ways to implement this: Add something to the move line or have a separate object. Because of simplicity I have chosen the first version, which coincide with the way they have done it. | ||
| 2012-09-18 21:13 <katr> cedk: The blueprint should be similar to the blueprints in the wiki I suppose? | ||
| 2012-09-18 21:14 <katr> cedk: How can I publish it? | ||
| 2012-09-18 21:21 <katr> cedk: Are there any particular difficulties your are foreseeing? | ||
| 2012-09-18 22:25 <cedk> katr: I can give you access to wiki, just send me your google account | ||
| 2012-09-18 22:25 <cedk> katr: I don't like to mix accounting information with document information | ||
| 2012-09-18 22:26 <katr> cedk: kantntreiber@gmail.com | ||
| 2012-09-18 22:27 <katr> cedk: With document information you mean the dunning process? | ||
| 2012-09-18 22:28 <cedk> katr: yes it is just information about document | ||
| 2012-09-18 22:31 <katr> cedk: I don't like it either. It was just the easiest way to achieve what I want. | ||
| 2012-09-18 22:32 <cedk> katr: for me, such design will exclude inclusion in Tryton | ||
| 2012-09-18 22:33 <cedk> katr: you have acces to wiki | ||
| 2012-09-18 22:33 <cedk> katr: the rules are: don't duplicate, use links, keep the structure, put comment for any changes | ||
| 2012-09-18 22:34 <katr> katr: As I already said, we can discuss and change the design. The push to the code review was just to get things rolling. | ||
| 2012-09-18 22:34 <katr> cedk: O.K. | ||
| 2012-09-18 22:44 <cedk> katr: my goal is to use a methodology to design modules for Tryton | ||
| 2012-09-18 22:48 <katr> cedk: It's a good thing, to have some kind of PEP-like process in Tryton. I just didn't know that it's necessary for something small like the dunning module. | ||
| 2012-09-18 22:49 <cedk> katr: I think it is not small | ||
| 2012-09-18 22:50 <cedk> katr: I have to think more about it but I see that we could make something better | ||
| 2012-09-18 22:50 <katr> cedk: But even with something small, it makes sense that someone not following review.tryton.org or the IRC channel to point out some issues. | ||
| 2012-09-18 22:50 <cedk> katr: but right now, I'm busy with the AR patch | ||
| 2012-09-18 22:51 <katr> katr: AR: I know, it's a lot of work. But I'm really looking forward for the next release. |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!