dneighbo (~dneighbo@ip68-109-180-32.ph.ph.cox.net) joined #gnuenterprise. derek (~dneighbo@ip68-109-180-32.ph.ph.cox.net) left irc: Read error: 110 (Connection timed out) jcater (~jcater@cpe-066-061-086-142.midsouth.rr.com) left irc: "Client exiting" Arturas (~arturas@gsk.vtu.lt) joined #gnuenterprise. Hello hi reinhard (~reinhard@M1264P004.adsl.highway.telekom.at) joined #gnuenterprise. btami (~tamas@ip102-205.ktv.tiszanet.hu) joined #gnuenterprise. good morning the summer has gone 15 celsius here and the scool year started LuftHans (~lufthans@wsip-68-107-221-207.ph.ph.cox.net) joined #gnuenterprise. once again, python requires a libc update :( lupo (lupo@p5085F082.dip.t-dialin.net) joined #gnuenterprise. Vee2d2 (~vin@c66.169.136.41.ts46v-07.otn-c1.ftwrth.tx.charter.com) joined #gnuenterprise. hohum... lesterb_ (~chatzilla@ash1-dsl-ws-8.dsl.airstreamcomm.net) left irc: "ChatZilla 0.9.28 [Mozilla rv:1.5b/20030827]" h2 (~h2@200.15.163.214) left irc: Read error: 54 (Connection reset by peer) btami (~tamas@ip102-205.ktv.tiszanet.hu) left irc: Remote closed the connection Arturas (~arturas@gsk.vtu.lt) left irc: "Bye :)" siesel (~jan@xdsl-195-14-222-172.netcologne.de) joined #gnuenterprise. hi siesel hi reinhard from geasList.py, line 88 # bug fix should be moved into common after the freeze self._datasource._datasourceDictionary={} has this been moved into common? hmmm, i think it can be removed. i find this in common: class _DataSourceWrapper(GDataSource): def __init__(self, *args, **parms): GDataSource.__init__(self, *args, **parms) self._datasourceDictionary={} self._toplevelParent = self._type is this the according fix in common? ok, then it can be removed :) yes. very good in gnue-appserver/language/ObjectList.py there are 2 fixes marked as fix for gnue-common 0.5.1 release (will be removed for later releases of gnue-common) do you know if they are fixed in CVS? yes, thats because of broken count methods for some db drivers This is still an issue ok hi! so we have to leave that in hi chillywilly siesel: you have another minute? yes i had some thoughts about our release planning there are rumours that sarge is scheduled for dec 1st for release that means that it will freeze somewhen in october i would like to see a as-useful-as-possible version of appserver in sarge yes. that means we have to hurry up :) :) i am still undecided whether it would be a good idea to include the authentication in the current form I dunno, but I think better any authetication than none i don't think we will support this rather primitive way of having a classlist for every user and i am not sure if we should include something in a release for sarge that we probably will not be compatible with in later versions ok, but we need authetication do we? yes. btw do you use appserver in production somewhere? I use it for the javascript client at the moment and I don't like to give access to everyone ok so you _really_ need authentication :) so what would be a type of authetication which is appropriate? maybe we should just include what we have now and document that later versions will possibly be incompatible? I think it would be easy to write a update script for this easy accesslist stuff yes you're probably right for the "final" version of authentication i think we need something with role based access control but - independend of the release- where do you think should access control heading to ok. every user should be attachable to one or more roles like one table "roles - classes" and one "user - roles" ? and every role should define access on the level of classes, properties, procedures yes to user - roles (n:n) GNUe as a whole needs RBAC ;) and roles - classes (where access can be read-only or read-write) the same for roles - properties and roles - procedures maybe even with ranges I thougth of something like "address_*" - "address_master_role" - "full" like the boss of department x may only edit the invoices of department x and view the other ones ok, the rules stuff, I "errinnere mich" any idea how to implement that? yes in my brain's attic i think we discussed that already a long time ago :) what about using the condition classes from gnue-common for that i don't even want to think about that before our appserver release for sarge hehe i really have a few things i want to clean up and/or fix what? well let me look at my list * document language interface and class repository * fix type definitions in appserver.grpc (siesel) ;-) hoho :) * do some performance tests analyzing postgres' logs * do some performance tests analyzing RPC traffic * update README, INSTALL and all that stuff * if enough time, cleanly implement boolean and datetime property types does gnue-forms.js exist out there somewhere? * cleanly remove (?) our trigger testing code so that we don't cofuse ppl looking at the code Vee2d2: yes at http://www.gnuenterprise.org/~jan/webfrontend/ ohh! thanks * some fixes in using common's datasource/resultset I can take a look at that trigger stuff whats wrong with the last one? i think there's something missing like we never actually close the connections hmmm, yes, that's a common issue also there must be a way to create multiple resultsets in one datasource so that we can use a single commit to commit changes to different tables otherwise our transaction is not atomar at all apart from that, appserver sometimes issues SQL statements like "select gnue_id from address_person where gnue_id = ..." that don't make much sense yes, that's strange. I think the whole database layer has to be reworked. i already know the reason and how to fix it database layer == in common? That's what I intended by moving everything into that "bclass" concept no, not necessarily ok well anyway there are two things that i would be glad if you could look at it because i don't think i know enough about common to do it myself if you have time no, but I'll try :) 1. i personally don't like the "geasv2" prefix in appserver's dbdriver it should be not a biggie to change that to "appserver", should it? siesel: :) me neither and 2. appserver would now support introspection (via the gnue_* classes) and my understanding is that we just have to teach common how to do that and then e.g. designer will be able to use it is that correct? yes, that's rigth ok, I'll take a look at that, but that all depends on the release shedule of gnue-common, basically i think appserver is in a state we can show it to the world (feature wise) almost :) procedures are still missing sure I mean methods i understand we agreed to call them procedures ;-) yes, because we work with business objects :) however i'd like our next release with no procedures at all, but with everything we have now really working, stable and documented instead of procedures started but not finished, and everything else also started but not really finished I think our interface to the world is good, and thats the most important, as that allows other programs to use appserver yes and i also think we will manage to be upward compatible from now on like the jsclient or a php client .... yep. btw. that means 0.1 release ? well, numbers are only numbers :-) we actually targeted 0.1 for working procedures but i can also agree with 0.1 our target release for sarge (and what we have by then) and 0.2 with working procedures for example thank god our ROADMAP file isn't read-only ;-) or 0.1.5 with working procedures, but no internal changes :) i acutally think our first release for the world should be called 0.1.0 its very important to fix all eventual memory leaks, to allow it to run appserver by init.d and for a longer time than 24h yes well my plan would be something like perfectly clean up and document what we have not (feature wise) and release it as 0.1.0 to a wide audience release subsequently 0.1.1, 0.1.2 etc as bug-fix releases if there are any and add new features for 0.2.0 ok. my opinion for a clean release system is that minor releases should have not new features, but only bug fixes btw. could you add the point listed to a TODO file in gnue-appserver= = -> ? yes at least the ones i won't fix within this week :) shall i add the 2 points for the appserver dbdriver in common's TODO ? no, not needed, I change the first thing now, and add a todo for introspection in the Driver file ok thanks thanks a lot btw i have a question on the .gsd files there is a tool in common to create SQL from .gsd but you seem to not use it but use sablotron(SP?) there are two: the xslt scripts and gnue-scripter is one of them depreciated? no, its more that jcater likes the python way, and I like the xslt way *lol* ah ok AFAICT the python way by now only supports schema but not data but in that case this is only a FYI yes, I added the data stuff, and jason doesn't seem to need that ah i see dcmwai (~dcmwai@219.95.59.5) joined #gnuenterprise. but I think it's not so important which tool to use as we should ship all files "pre-compiled" yes of course i just was insecure which tool _I_ should use :) and later we won't need these files anymore as appserver will create tables on demand hi dcmwai yep hello siesel that's another missing feature in 0.1.0 probably exciting stuff.. Vee2d2: nice to hear :) reinhard: We possibly shoud define a table layout for the whole 0.1.0 series and name the release 0.1.0 because its all defined, and in some cases just not implemented you think we will implement some more features in the 0.1.0 series? I dunno, but we should probably stick with that old release plan we can also add these new features to a 0.2.0 release, but define everything already in 0.1.0 I dunno, I just think that 0.1.0 should be more that just the release for sarge but as you said earlier, its all just numbers, so I don't really care :) i'm not sure if we want to define the table layout now and implement the functionality later yes, that way has some major drawbacks in defining the table layout we already make a lot of decisions about the later implementation i have learned to take decisions at the latest possible point in time or in other words yeah, your right. "planung ist die ersetzung des zufalls durch irrtum" but we probably should state clearly in the readme what appserver 0.2.0 will be look like yes we should have a clear roadmap i agree 100% we need that so we can break it again ;-) *LOL* btw. another point is that webfrontend I've written its just a way to load html form definitions + jsclient library from the appserver siesel, is it :) s/:)/? when can we test it? I know it shouldn't be integrated into appserver, but be an addon you load form definitions from appserver? http://www.gnuenterprise.org/~jan/webfrontend/ dcmwai: you should take a quick look at the logs probably.. they've had a pretty good conversation going on.. :) Vee2d2, Will do (today log?) yes siesel, Not bad :) yes, you can use the xmlrpc implementation as a webserver, so you can just point the webserver to appserver port load the html file and it will automaticly connect to appserver hmmm it's against that lean model of appserver we agreed on, but its quite useful and it possible could be moved into a plugin it sounds like a very useful thing but i agree it would be better to have it seperated it is a very usefully things :) ajmitch (~ajmitch@wlg1-port21.jetstart.maxnet.co.nz) left irc: Excess Flood lxf (~agus_tea@202.73.120.115) joined #gnuenterprise. separated? how it will be separated? ajmitch (~ajmitch@wlg1-port21.jetstart.maxnet.co.nz) joined #gnuenterprise. for high load the files should be loaded from a real webserver like apache, and just the xmlrpc communictation would be with appserver jcater (~jcater@cpe-066-061-086-142.midsouth.rr.com) joined #gnuenterprise. wb ajmitch, mornin jcater morning jcater and of course wb ajmitch :) Action: dcmwai finish reading log... morning all norming jcater. good evening all hi lupo hey siesel morning jcater nice to read you :) uggh I hit a nasty deficiency of GNUe this weekend one jamest hit a few weeks ago too It can't produce donuts? that too GNUe has a deficiency! the sky will fall on us! I think, in addition to changing internal representation of strings to unicode, we are looking at changing internal representation of floats to a Decimal type as floats aren't going to be accurate enough for doing business calculations this weekend, I installed the point of sale app at our store since I was running thee store for the weekend jcater: you mean, a float represented as two integers one payment I could not enter at all as the tax couldn't be represented with a float :( ? isn't that a limitation of your app? lupo: yes, though there are classes for python that handle that efficiently perhaps but if gnue is to be a library for business apps it should hide the fact you'd need 2 integers to represent any number imho of course, we both knew the limitations of floats from past experience, but, um, seemed to overlook that when doing the libraries :) how were you not able to represent a tax with a float? a matter of precision? yeah it screwed up comparisons e.g., go into python and type .1 Wow, you got more than 83886.08 dollar in a bill ? 0.10000000000000001 -> wtf ? interesting erm when i assign a float to a var, i don't see any problems http://www.python.org/doc/current/tut/node14.html okay, i get your point. how will two integers help you with that? floats can maximal represent 7 digits, or a value up to 8388608, as thats 2^23 mkay i get your point. the other 9 bits are holding the exponent only so how do you intend to solve that? http://fixedpoint.sourceforge.net/ or, "what is a decimal type?" i know BCDs from dbase :-) that was intended to be included in Python 2.3 but it didn't quite make it in time but it is available as a package (on debian sid) ah looks fine if the license allows, we may pull it into our cvs tree so user doesn't have to install yet more stuff license is: Python Software Foundation License The License of Python 2.0.1, 2.1.1, and newer versions. This is a free software license and is compatible with the GNU GPL. http://www.gnu.org/licenses/license-list.html other than this one error, gnue point of sale rocked at the store define "rocked" worked well http://www.python.org/2.0.1/fsf.html I guess 'rocked' could be 'wickidly unstable' ;) jcater: you can import fixedpoint to gnue cvs, license stuff has been clarified. cool I think an upcoming version is going to highly standardize what a dbdriver returns the python 2.3 license even makes it clear that it is GPL compatible. expressis verbis. I know siesel is wanting to make all strings be unicode we're considering this numeric thing and I've had issues w/datetime instances as some dbdrivers want to provide their own DateTime class I think an upcoming version is going to highly standardize what a dbdriver returns <--- is that a threat? :-) that isn't necessarily compatable w/the way we want to use it so I think we're going to say, f.e., dbdrivers will return one of the following (and only one of the following): unicode string, fixedpoint number, or (specific) DateTime instance, or NULL s/NULL/None sounds good I hit the datetime issue with my Oracle dbdriver yes, that would be good seems it wants to return its own homegrown OracleDate instance which doesn't support string formatting very well Action: lupo is away: learning physics as we then would have a strict interface, which should be reasonable easy to test for all db drivers for compatibility jcater: so you got bit on the ass by the float limitation? ;) jcater: i have a question on datasources in common is it possible to create more than one resultset (from different tables) with a single datasource? or the even more correct question: what is the right way to do a transaction that changes data in more than one table? (AFAIK "commit" is on datasource level) well this is something that needs to be cleaned up commits are actually on a connection level but there's no easy way to get to a "connection" object in your code so you have to go through a datasource to do it Action: jcater looks for sample code... ah so if i commit any datasource of a connection i commit the whole connection? yes, currently ok how can i tell whether a datasource should use the same connection as another existing dataasource? pass the same connection manager? I believe if they have the same connection="whatever" setting which I guess we need to change, as that won't work for appserver Action: jcater needs to run for a minute I think we could disable "connection caching" in GConnection.py on demand, to allow a new connection to be created R45 (~rastabeen@200.108.1.99) joined #gnuenterprise. I don't remeber if its in GConnection.py or in GDataSource.py or set up some "session" concept lxf (~agus_tea@202.73.120.115) left irc: Client Quit jcater: i agree jcater: another question (if you still have time) that would be a good place to add RBAC IMHO is there a way to "close" a datasource and/or resultset ? hmm sadly, I don't remember the answer to that question it would be logical to be able to but I'm not sure it has come up all my sessions end with Sep 1 18:19:04 london postgres[32197]: [19] DEBUG: pq_recvbuf: unexpected EOF on client connection and that looks like the connection to the sql server isn't closed properly anyone have a minutes here? is there any know problem on designer? [dcmwai@dcmwaisrv gnue-forms]$ gfdes Traceback (most recent call last): File "/share/gnue/.cvsdevelbase/gnue/designer/Designer.py", line 382, in ? Designer().run() File "/share/gnue/.cvsdevelbase/gnue/designer/Designer.py", line 92, in __init__ wxApp.__init__(self,0) File "/usr/lib/python2.2/site-packages/wxPython/wx.py", line 1802, in __init__ _wxStart(self.OnInit) File "/share/gnue/.cvsdevelbase/gnue/designer/Designer.py", line 102, in OnInit from base.startup import Startup ImportError: No module named startup anyone face this or I'm the only one dcmwai (~dcmwai@219.95.59.5) left irc: Remote closed the connection dcmwai: are you sure you have the latest cvs checked out? oh, he left Action: jcater is away: printing checks dimas (~dimas@195.218.177.46) got netsplit. jcater (~jcater@cpe-066-061-086-142.midsouth.rr.com) got netsplit. LuftHans (~lufthans@wsip-68-107-221-207.ph.ph.cox.net) got netsplit. chillywilly (danielb@CPE-24-167-193-166.wi.rr.com) got netsplit. siesel (~jan@xdsl-195-14-222-172.netcologne.de) got netsplit. Vee2d2 (~vin@c66.169.136.41.ts46v-07.otn-c1.ftwrth.tx.charter.com) got netsplit. lupo (lupo@p5085F082.dip.t-dialin.net) got netsplit. icltlfatppl (~icltlfatp@157.22.13.237) got netsplit. dneighbo (~dneighbo@ip68-109-180-32.ph.ph.cox.net) got netsplit. ajmitch (~ajmitch@wlg1-port21.jetstart.maxnet.co.nz) got netsplit. reinhard (~reinhard@M1264P004.adsl.highway.telekom.at) got netsplit. Stoke (~stoker@dpvc-141-149-254-50.buff.east.verizon.net) got netsplit. tripz_ (~ville@as13-5-6.ld.bonet.se) got netsplit. havoc (~havoc@CPE-65-31-122-112.wi.rr.com) got netsplit. R45 (~rastabeen@200.108.1.99) left irc: ajmitch (~ajmitch@wlg1-port21.jetstart.maxnet.co.nz) returned to #gnuenterprise. havoc (~havoc@CPE-65-31-122-112.wi.rr.com) returned to #gnuenterprise. tripz_ (~ville@as13-5-6.ld.bonet.se) returned to #gnuenterprise. Stoke (~stoker@dpvc-141-149-254-50.buff.east.verizon.net) returned to #gnuenterprise. reinhard (~reinhard@M1264P004.adsl.highway.telekom.at) returned to #gnuenterprise. dimas (~dimas@195.218.177.46) returned to #gnuenterprise. alandd (~alandd@h-68-165-192-9.PHNDAZ91.covad.net) joined #gnuenterprise. jcater (~jcater@cpe-066-061-086-142.midsouth.rr.com) returned to #gnuenterprise. siesel (~jan@xdsl-195-14-222-172.netcologne.de) returned to #gnuenterprise. Vee2d2 (~vin@c66.169.136.41.ts46v-07.otn-c1.ftwrth.tx.charter.com) returned to #gnuenterprise. lupo (lupo@p5085F082.dip.t-dialin.net) returned to #gnuenterprise. LuftHans (~lufthans@wsip-68-107-221-207.ph.ph.cox.net) returned to #gnuenterprise. dneighbo (~dneighbo@ip68-109-180-32.ph.ph.cox.net) returned to #gnuenterprise. icltlfatppl (~icltlfatp@157.22.13.237) returned to #gnuenterprise. chillywilly (danielb@CPE-24-167-193-166.wi.rr.com) returned to #gnuenterprise. that's what they call a netsplit Kerwhomp! siesel: do you remember that once you tried to convince me alandd (~alandd@h-68-165-192-9.PHNDAZ91.covad.net) left irc: "Client exiting" that once a list is requested yes? R45 (~rastabeen@200.108.1.99) joined #gnuenterprise. it shouldn't be changed by subsequent "store" or "delete" calls? i mean I can't remember, but it seems that's the status quo aehm yes ok i argued that the changes should be reflected in the list and you said that it's better to have a stable "resultset" like in a database ok, I remember well now after some months i believe that you were right and we should leave it the way it is now I meant it would like a "cursor" yes exactly ok. you still have the same opinion? Yes. if yes i can remove a bunch of TODO's and FIXME's from the code i added then good