*** wendall911 has quit IRC *** btami has joined #gnuenterprise *** reinhard has joined #gnuenterprise *** bluesbaron_ has joined #gnuenterprise *** bluesbaron_ has left #gnuenterprise reinhard: cleber cited http://modeling.sourceforge.net/ yesterday it's all about gnue-common and gnue-appserver it's sad, they not in gnue team... i think they don't do *exactly* the same as we however probably somehow related yes *** johannesV has joined #gnuenterprise *** holycow has joined #gnuenterprise *** mixi^ has quit IRC *** mixi has joined #gnuenterprise *** kilo has joined #gnuenterprise *** SachaS has joined #gnuenterprise good morning morning ello hi killo holycow kilo have you tried the new .gcd what are the currently supported gnue-appserver triggers? OnInit OnChange OnValidate OnDelete (i think i forgot one) it should be documented in api.txt ok. thanks heh the gcd is working for me reinhard and the testRPC.py/test.py as well the gnue lists are quite active neat ayess, new .gcd is candy ok. okay so SachaS and kilo you would be ok with releasing the current state as 0.0.8 ? once there is the next step, that you can install a .gcd straight in a running appserver ? we want to do that right after the release johannesV is already working on it but we want to do the relesae release first reinhard: when? string freeze? i need one evening to check strings ok. would it be possible to have the python code checked? kilo: i will do prerelease (hopefully) today like take the code of a procedure and try to import it, if it bails out, the appserver does not load the .gcd prerelease == string freeze what is string freeze? regarding the bug tracking system on the mail list... why not write one in gnue? a: should be dead easy SachaS: string freeze == no changes in strings, so that translators can do their work in piece b: would reinforce the eating dogfood comments :) oh ok. kilo: after prerelease, there will be at least 3 days until official release so enough time for you of course i am ok with it. reinhard: if i have a two-tier app, referreing fields like datatable.field, can i simply change the underlying datasource to appserver and use that gfd intact? Or must i use module names? SachaS: i will have to think about that python check thing ok for the prerelease then ok. kilo: you can not simply switch from 2-tier to 3-tier with 3-tier, you have to follow the rules wrt table/field names e.g. module_identifier syntax hmm every table must have a gnue_id that is the primary key that IS a problem we think switching to 3-tier should be just a decision i think that doesn't make sense because if you can switch from 2 tier to 3 tier without changing something optimizing is an other question why should you use 3 tier at all? you would not make any advantage of appserver's features you wouldn't have any triggers or procedures you woudln't have any calculated fields you would have all logic in the form so why use appserver at all? holycow: afaik DCL is written using gnue or not kilo: no not, it's php ok, btami told me kilo? no it's all php from what i can tell ok, i go back to my ole mars... i think one issue is: who is brave enough to host the gnue-appserver on a world wide accessible address/port. if i had linux skills i would without question so the problem is that it is a must to change the gfd when switching between 2- or 3-tier i'm getting there bit by bit, but in no way feel competent enough to do so reliably kilo: i think the bigger problem is that the database schema must change yes, also problem it should be without module_identifier if one has only 1 module btami: that could be a solution also, appserver could have a feature that you can define what is the pk of a table instead of assuming gnue_id however currently appserver is targeted at writing new applications not at being integrated into existing ones that's the main difference i think between the 2-tier and the 3-tier strategy ok, i think i understand now a bit better thx these two features would be great (pk, 1-module mode) actually i like to dogfood idea holycow: derek started to write some gfd for DCL, and jan made a grd IIRC but things stalled i think its a matter of finding a person a person supporting/enhancing it dogfood is great as it makes your teeth and hair shiny and strong and if done with appserver, all developers should agree to using it, even when its running on appserver ok, so we all hereby unanimously sign SachaS as main head of development of a bugtracking gnue sortware, not forgetting dogfood of course actually i think the idea was to have a project management gnue package where you can manage different projects and each project could have a bug tracking sub-module ;) submodule? maybe class. reinhard: you are a small firm, am i right? kleine firma kilo: yes *we* (johannes, sabine and me) are a small firm and how do you manage payroll calculations? tax consultant :) oh, so is it outsourced? yes it doesn't make any sense here to do it yourself law changes all over about twice a year same here you would have to spend several days a year just to keep updated to manage to do the work that is acutally an hour a month or so so it's not worth doing it oneselves ok. in fact we are looking for some information about payroll systems in other countries i don't know jack about payroll in austria and how should we gain some info about it btami, re: dcl on gnue, neat! i didn't know anything existed i wasn't able to understand my paycheck for all the years when i was employed is your tax consultant good at english and irc? 8-)) to have a project management gnue package <-- thats probably a bit too ambitious perhaps getting an application suite out the door that everyone could agree is 'the current stable whatever' to develop to and patch as upgrades are performed may be something to think about and do a simple bug tracking dealy just to start... that should be challenging enough to host i think kilo: lol so you cant answer if the payroll systmes are like eachother in at/de/li/ch? hi *** holycow has quit IRC hi ajmitch kilo i would not know. but could pass you a person, he might be interested. oh that would be great you know we want to build the new payroll system from scratch and if so, we think we could use such informtaion for future purposes kilo what are you interested in? a payroll system does that include tax and things? yes, how does payrolling work in other countries yes, tax, insurance and such ok. i sent an email to a friend asking if he knows anything about it ;) his pride will say yes, then I ask him if he could help ;) ok thx lol its 11.20 and I havent done a thing outch same goes here *** roby has joined #gnuenterprise you are wrong. we had breakfast, we had coffee, and now it is time to think about lunch 8-)) *** roby has quit IRC *** jproby has joined #gnuenterprise *** btami has quit IRC *** btami has joined #gnuenterprise * kilo falls in love with gcd2sql gcd question: are calculated properties of type string to be typed with no length info? i would say with lenght info length even *** jproby has quit IRC *** btami has quit IRC gcd2sql gives error msg then oops i used an integer as my test calculated property, with scale and length might be a bug you can lodge it at the bug tracking system ;) or fix it ;) ot better, ask johannesV... *** dcmwai has quit IRC kilo: have you got the latest svn-version; i did a bugfix yesterday (concerning lengths and calc-fields) hmm, i think no ok, svn upped, it's ok now johannesV: is it really needed to name tables like module_class and properties like module_property isnt it overdefined? makes it quite hard to use in code *** btami has joined #gnuenterprise kilo: you have a default context which is the module the current procedure is defined in so if in the foo module you have a procedure and in that code you want to access foo_bar.foo_baz you can as well write bar.baz ah but if you want to access properties from "foreign" modules you have to write e.g. bar.other_frob that's good news so in current module i dont have to use fully qualified names, only when reffering objects outside of the module exactly well, then you must persuade btami why use underscores... and i note that naming classes and properties the way it is now when definig constraints, max identifier length is easily hit you should not elaborate too much especially on module names the background behind this module/namespace thing is imagine you write a payroll system oh unimaginable that has a class "person" SachaS writes a erp system that also has a class "person" i want to combine both on my server i can do it because the tables are "payroll_person" and "babyerp_person" and procnames need it because i can do kind of generalization and inherition ? and expand one class' attributes with other attributes in an other module and still: why underscores? btami can't sleep well if can't get an answer 8-)) properties and procedures for the sake of one module expanding another module yes and we need two different separators one to separate class/instance from property/procedure and the other to separate module from identifier they must be different to make things syntactically determined and apart from the underscore, there is no character that is valid in python identifiers can't we make it like moduleFoo.classBar.propZing? no foo.bar.zing is not determined it could be module class foo.bar property zing or it could be class foo property bar.zing can a property name be like bar.zing? yep bar being the module apart from that even if we managed to make foo.bar a valid classname foo.bar would never be a valid table name for the db true so we must go for underscores in the db table which again means we may not use underscores in identifiers anyway or we would mess up the table names and cant appserver map foo.bar to foo_bar tablename? could yes but if we have a class foo_bar.baz and another class foo.bar_baz which tables would you create? that's easy, i would create a table named 'Ni' 8-) *it* would not work, *it* would be wrong ;-)) by the previous exampe, do you mean SachaS and we developped two totally different systems, but one would like to use it with one appserver instance? exactly that will happen in practice you and SachaS would not even know of each other's modules but they still would be compatible as long as the module name is different so for "official" packages, one just has to register a module name and can play safe whatever he wants that's the idea behind all this module stuff so noone should use module names like 'universe'... i think this is wrong fundamentaly why? erm what is wrong actually? i think in a gnue system the goal we've set or the way we want to reach it? there should be only 1 database this needs a database design it means one thing has one name and one name means only one thing this is the base of database development how can this work in a decentralized development? if we want to develop gnue packages they need database design they can't be independent they can be separated packages but in one well designed database otherwise it will be diversed, and all bad things comes from underdesigned databased databases i think packages can extend other packages tables but not owerwrite the same thing(field) in the same table btami: i basically agree sigh, ok the plan was to have "official" apps that are well designed and have a really good db design but there will be lots of people writing lots of independent (inofficial) modules for gnue anyone answered that email about commercial support? :) i think they all have to care the database design of official gnue packages if you want to use together imagine, there is 15 not official gnue packages define the name of a person ajmitch: no it's makes no sense kilo: yes for not 'universe', but 'milky way' is possible :) dimas: i prefer nestle i guess if non official package X needs non official package Y, then those two projects will have to work together... i think the goal of gnue is not to manage non official packages to work together work together = make sure they can be used together = they both provide a good database design so that they work together well without good database design btami: i don't expect non-official packages to redefine the name of a person but gnue cannot control non official packages so its up to the people who develop non official packages that they work nicely together let me think of a more practical example we have a special tax law in austria that forces you to send a specific report to the tax authority and if someone wants to have their non-official gnue package become official, they have to pay 10'000 to the gnue foundation ;) just a joke you have to classify your accounts to be able to build this report yes, a joke, they have to pay it to me... so there will probably be an .at specific module that extends the basic accounting module by this classification most probably there will be about 100 country specific extension modules to accounting all defining some fields that are only used in that country i don't think it's manageable to have a central db design considering all those needs OTOH, companies e.g. having offices in 2 or more countries will want to install both coutry specific versions into one database might even be that both these country extensions define a field named "TaxClass" for the account table i hope i can explain this stuff well enough so you can understand what i mean :) i understand, but in this case i prefer tu use ATTaxClass and HUTaxClass as names s/tu/to but i understand it just don't like _ for this :) maybe __ would be better :) would make the identifier length problem even worse :) hmmm, yes :( i think it's not that bad once you get a bit used to it at_TaxClass and hu_TaxClass if I'm really honest i like that better than ATTaxClass and HUTaxClass yes, i'm trying :) if people start to develop official/non-official gnue packages its important to have guidlines it is only problem because many people will use underscores in names u need camelCase for names kilo so yes, it should be printed in caps that naming convention in appserver is camelCase and underscore is needed for something else it is hard to change what people were used to for years it will be exciting when the start/restart of the gnue packages will happen i would have given what you want if there were a better possibility than the underscore there will be some organisation necessary but we needed a character that is not a letter or a number and still is valid as well in python identifiers *and* in database identifiers and the underscore was the only char that fulfilled this need oh, so jolly rogers is no good choice i have a python related question i have the python wrapper for the xmlblaster message oriented middleware (mom) actually its a couple of files including the xmlrpc.py file this file is causing me prolbem, when using testRPC.py in the same directory is xmlrpc in python 2.3 ? so that i can import the python2.3 xmlrpc library and remove the xmlrpc.py file I got with the python xmlblaster client library (actually only files)? trying by just deleting the xmlrpc.py file I got yes working. OK! its working. * SachaS is happy SachaS: you can safely delete the xmlrpc.py file, it will work that way too gnue-appserver <--> gnue-interface <--MOM--> bsi A <--net--> bsi B <---> biz-application both ways Now I'll send you my invoice of $500 for this advice inventory request going from biz-application to gnue-appserver. inventory response going from gnue-appserver to biz-application kilo_consultant: I have a produced called babyerp for you, that does invoicing realy well. makes $10000. thanks lol reinhard, johannesV its woking, the setup on the diagram ... its working! in fact my invoice app printed invoices qith dates due like 33203... well i dont want to wait that long... we have gnue application integration ;) with ebXML collaborative business processes (not 100%) and ebXML messaging (not 100%). the sky is the limit hurray its all a bit shaky but its a proof of idea ;) reinhard: did you see my thoughts about a .gid file? gnue-application interface description ? actually I am impressed with johannesV short code for the gcd2sql. i think i have not seen one sql statement in it. seems like organisde :) man i reached my goal for today. i think i go to the beach beach in li? are there not only mountains??? :) your right. can you beach at the lake of Boden? yes you can. kilo: it's acutally called lake of konstanz SachaS: gcd2sql why should there be any sql inside :)) *lol* i am impressed it works gcd2sql i think it is getting better day by day i am the only one happy in here? that's great, isn't it ... but i'd be happy if i would have a clue how to start with Schema.Creation so what does that do? Schema.Creation? reinhard: i swear we call it lake of Boden we also bodensee Schema.Creation is the capability of datasources or their drivers to handl SQL-DDL however boden in german is the ground or the floor s/handl/handle/ what is DDL ? Data Definition Language like 'create table ..' and so on never heard of it ok. i think sql-ddl belongs to drivers right, this is implemented in the drivers koz it's wery db specific as we learned from jcater yesterday it's even more specific so like oracle can have different ways of doing it, depending on version johannesV: am I understanding right: lets say we have class A with property b and property c. I update the .gcd file and create a new sql file. the updated .gcd adds a d property to class A. Are you trying to update the database? basically you see that there is a class A and it has a b but no c. so you do a table update so that it has property c. SachaS: exactly s/adds a d/adds a c ok. SachaS: exactly that is what doesn't work now and we want to make it work well not quite thats after 0.0.8 ? we wouldn't create a new sql file that adds c right, this cannot work at the moment, because gcd2sql cannot know which gnue_id the extend class has ok.