*** Remosi has joined #gnuenterprise *** btami has joined #gnuenterprise * holycow sends 42 large pizzas with extra anchovies over to 414-810-8644 :D hope he's not allergic to fish :) *** johannesV has joined #gnuenterprise *** holycow has quit IRC *** Remosi has quit IRC *** kilo has joined #gnuenterprise *** reinhard has joined #gnuenterprise *** SachaS has joined #gnuenterprise morning all morning SachaS hi kilo howyadoin oh, btami just left, and his xchat beeps on each message... good thanks i'm just playing with umbrello kilo, also have a look at argouml. that seems to be a quiet mature project ... there is a argouml debian package that is in java, isn't it? it is yes. with bsd licence. java a too big issue for you? i dont really like it java ? or what dont you like? yes, java ok. even as a tool to use? i am aware of the "java is not free" problematic. so my idea was to have any uml tool exporting XMI, so it does not matter what uml drawing tool you are using, as long at it can export a common format, such as XMI. then we can write ONE transformation tool for XMI2gsd then "we" can write ... -> then we have to find "someone" who writes ... ;) ah, yes, SachaS is getting more and more accustomed to gnue thinking 8-))) but isnt XMI diverse? kilo: actually I am not sure. there should be a way to express UML diagrams in a tool independent way. So I thought XMI does that. But good point. just read on the argouml homepage that different XMI-exporting tools generate different XMI... sad thing vi x hehe oh, indeed sad thing. hi reinhard reinhard: what do you think about yesterday's talk which talk? with Sacha here on irc, about a descriptive language *** dimas_ has joined #gnuenterprise using a uml tool to draw gnue packages, gnue classes, gnue properties, gnue procedures etc. drawing a uml class diagram then generating a .gsd or anything appserver can read. yeah i think i already said that would be übercool :) ah, ok 8-)) have you been involved in the half-finished gnue-packages development? half-finished? you are quite optimistic ;-) yes i was involved ok, partly finished 8-)) i feel like when i had to interview a teacher when we were running the schoold radio, and he only answered yes or no... :) would you please share some thoughts about tha packages development, and the recent chat about blablabla ? 8-))) just a sec ok as for the tool to use to define the objects for a long time i thought using classrepository.gfd would be an ideal and prefered solution that was before i tried it myself :) rotfl there will probably be different ways of authoring class definitions, depending on the people classrepository.gfd might be the correct tool for an accountant that wants to add one or two properties to a class for real projects you really might want to hav an uml builder and import that into gnue and, afaict now, i probably won't use any way to author class definitions that i can't do in vi we have talked (in real life) yesterday about a new ".gcd" format designed to manually edit class definitions, based on xml like off .. see you later. i cheer to reinhards idea :) reinhard: now i can remeber this way of definition ... i suggested it for a replacement of repository.ini this was about 3 or 4 months ago johannesV: yeah, i remember :) kilo: what would you think was *your* prefered way of authoring class definitions? i like this gcd thing very very much me too we should use a language (and by language this time i mean a common interface) that can be used by both an accountant, only knowing how to start mahjongg... and both the developers so it should be VERY simple, but poerful you think xml was usable for this? in fact I like the format that exists in the gnue-packages directories too but that may be just because i like C++ and assembly... that format is a PITA first of all, you have to write your own parser and it reminds me of C++ classes... which is the reason why i played with flex and bison for weeks and if you make a mistake with the braces, you f2k up the whole definition i don't like such a format, cause we need an extra parser and if there will *ever* be our own graphical designer for gcd files (for example as a part of gnue-designer) it will be much easier for that designer to write xml files than anything else yeah please note that i am proposing a sort of compromise i did not write i wrote because i think that is much better readable by humans that's correct although it's not "pure" xml we can also do something like: here comes the code and it automatically translates to a procedure "getfoobar" ... might be a good idea, yes or which creates a proc "address_onInit" ... using proper params and much more I hereby request the formation of a .GCD commitee and a proposal for .GCD standards!!! well actually the module-attribute would be obsolete since the definition is child of a class which is child of a module kilo: i think we should delegate that to OASIS :-P :)) and another dead tree would be needed yea :-)) what else did you talk about on that secret meeting yesterday? if things as good as this, i am very curious * reinhard tries to remember Sacha showed us how ebXML works we talked about what would still be needed in the front ends to build good applications (forms reports) btw how stable is the native windows forms ui? one of the most stables i think more stable than wx, that is for sure then it is for sure the most stable one because gtk2 is far behind wx curses currently does not even start and IIRC qt is also unfinished yes, that is exactly how you said fwiw i prefer gtk2, so it should get more current wx has sooooo many problems thoug i understand why it was chosen and that Jason does not want to rewrite designer... i am planning to work on curses and document a bit of what i learn there so we might have a kind of "howto write an ui frontend" at some point it would be great if curses ui worked *** reinhard_ has joined #gnuenterprise *** reinhard has quit IRC well, umbrello quit suddenly and cannot reload the project i saved only 1 minute before it crashed... bye bye umbrello... bye *** btami has quit IRC *** mixi^ has quit IRC *** havoc has quit IRC *** mixi^ has joined #gnuenterprise *** wayneg has quit IRC *** havoc has joined #gnuenterprise *** kilo has quit IRC ok. anyone considered: myName isHuman numberOfIntegers SachaS: this would lead us one tag per datatype which is too much because we can "keep it small and simple" by using one property tag with multiple type-attributes another thing is that this way the name of the property is one level deeper than the property-definition itself birthDate so i would prefer: i understand what you say. with one tag for all data types you have optional elements such as length which are mandatory for some but not for the others. so if one has to change datatypes it would be less effort to do so exactly, and the program to handle all this stuff would be a little bit smaller as far as i know, thats a rule you cannot define in an XML Schema *** kilo has joined #gnuenterprise actually i am not sure if there are any schemas at all in gnue world. isBorn would be valid but length does not make sense actually this should read: ok i am also happy with name being an attribute so one could use the tag's value for default-values (as an example) it is up to the parser to deal or not to deal with some properties, based on eg the data type as i see things, name MUST be an attribute why must? not a value of a tag, which would push the property name into the next xml-level why is that a problem? you can access the value very easy: xmlNode.value (in ruby with rexml xml parser at least) that might be, but it's then a child-element of the property its xml engineering decisions. there are pro and cons. but the name of a property is not a child-element but an essential information of the property itself (i mean in a logical point of view) so, why should we tear them apart ? i am with johannesV in this question http://www.medbiq.org/technology/tech_architecture/xmldesignguidelines.pdf xml guidelines from some people i have no problem with name being an attribute ok how about different elements for the different data types? you could reuse those xml element types also in procedures i am not sure about it just a thought i just know, that some things you cannot express in xml schema, such as: if you chose value x of attribute n, you must also set a value for attribut m actually we could consider using xml schema datatypes oh i think that would result in having an xml element for each data type. SachaS: i'm not sure what you mean with this ... ? ok. yeah i can think of having 100 where 100 is the default value *** dsmith has joined #gnuenterprise SachaS: yeah, as i've said before ... :) this xml-snippet defines a property-object and a value for it, both diffrent objects and instances actually we have to consider that we have different xml files maybe an xml file for each package ... seems not to be a problem... of course, but this isn't a problem it would be the usual case anyway johannesV: one question currently we write the .gsd file, then create the sql file, then create the db (run sql file), then start appserver. appserver uses database to access objects. right this process could be shortened a lot :) like manually editing the db 8-)) *lol* are you intenting to put the a) create sql file, b) create database tables be moved into appserver? lol well, at least some kind of tool which can read a gcd file and put it somehow directly into the db yes, that should be developed by someone 8-))) i see 3 ways of using appserver: a) read gsd/gcd file to install/create application, b) update application with new gsd/gcd file c) run application *** nenhum has joined #gnuenterprise i'd do that ... as it seems by now :) ah, lovely basic... 20 kilo goto home *** kilo has quit IRC *** Amorphous has joined #gnuenterprise *** jamest has joined #gnuenterprise *** Morphous has quit IRC *** nenhum has quit IRC *** __aaron__ has quit IRC *** johannesV_ has joined #gnuenterprise does a gnue-appserver trigger have parameters? SachaS : yeah they only work on monday through thursday from 4am to noon eastern standard time *** bluesbaron_ has joined #gnuenterprise SachaS: no, they have no parameters ok. thanks derek? *** btami has joined #gnuenterprise jamest: do something with svn, please! *** johannesV has quit IRC SachaS i was being funny not serious apparently the humor was bad (and didnt cross languages well) btw. derek: what do you think about starting a new .gcd format for business object? have you read the log? *** jcater has joined #gnuenterprise jcater: do you know why svn halts after cron dumps every day? svn: Berkeley DB error while opening 'revisions' table for filesystem /var/svn/gnue/db: Cannot allocate memory btami: i have not read log * derek is pretty adamantly against "objects" i want an app server not an object server there has been much debate (and likely at some point either this project or appserver will fork over this issue) objects = appserver objects = tables+procedures but now you are adding appserver objects that does not sound promising too me on many levels btami: i've tried about 20 times to explain it's void it's not void. lol i have not had time to look at it whenever derek hears the word "object" he doesn't listen any more nor had time to review it he did not even try to look at appserver at any point just because we use the term "object" im just saying up front, that it has not been fruitful in the past reinhard: that is not true reinhard: you have to find another term for business objects for derek :) bbl have to prepare dinner for kids i tried to use appserver a LOT pretty recently i could not get it to work right it was fundmentally broken the gut reaction was "you have to run it with certain parameters or it crashes" no one was willing to fix that problem so i stopped as i know, it works now i am HIGHLY interested in appserver me too it was not usable to my needs at the time of implementation and i can not get the proper support needed that i get from 2 tier mostly that is a time zone issue (not a personnel one) i like how i am lumped in as shutting down when hearing the word object when there are at least 2 others here that are not pro-object server im not against objects (Really) im just no pro objects i have stated the position that as long as it stores data relationally (in form not just format) i am pretty okay with it however, last few times i ahve seen tables "extended" to hold object information to support objects... which starts to deviate but honestly it's not my call i am merely one opinion you asked...i answered... reinhard got his panties in a ruffle i dont have time to read the irc log... a proposal in pdf format would be nice then i could print out and read during the commute btami: if I knew that, I could fix it =) http://sqlobject.org :P derek: use Zope ;) * chillywilly runs away i mentioned this issue (.gcd) just koz i think without this nobody can start any gnue packages derek: fwiw, as reinhard has explained it to me, and from what I've read of the docs, I sincerely believe this is just a breakdown in terminology jcater: quite likely that is the case I hate the word "object", as that gets new people thinking in the wrong terms but it's kind of like the word "free" in free software http://www.ambysoft.com/agileDatabaseTechniques.html can't come up w/anything better http://www.agiledata.org that site rocks as i understand the real data is stored in rdbms in , and don't minds is handled from 2 or from 3 tier app btami: well that passes my litmus test but remembered "stored" in rdbms is not same as relational function/form not saying what you are proposing isnt, just pointing out they can be different as if you store the data in relational system but ignore all the technics of relational systems it buys you very little the appserver holds the so called "metadatabese/schema"+procedures/triggers in another database http://www.agiledata.org/essays/mappingObjects.html derek: what do you want from the appserver? please read the api from appserver doc dir i think it's very clear, and it's what you want from it http://www.ambysoft.com/persistenceLayer.pdf *** SachaS has quit IRC * chillywilly is the url spammer btami: api's are not "very" clear in my opinion they are dry reading that leave lots of questions *** SachaS has joined #gnuenterprise what i want from appserver is my logic moved to a central location jcater: what about to start a "kill" cron after 1 hour a dump job for reuse as well as deployment purposes i also want ability to scale that tier the ability to "control" logic implementation is highly valuable as well so if i have a new business rule i can dictate when to "implement" it that is i can stage it for implementation to the systems in a number of fashions i think things you are talking about are independent from the need of a .gcd standard i mean, people (not the tool programmers) can't work on designing packages without that maybe i'm wrong... so if i have a database right now today that meets my needs and i have two tier forms that i can use against this (ie i have a "package") i can't use appserver? * derek isn't saying that is bad, right, wrong or indifferent (in fact it would explain alot) i think you can use the appserver now just as another dbdriver just you have to populate its classrepository with schema data module=yourpackage class=table property=field * btami hopes reinhard will explain all of these more cleaner so where does the gcd come in? jamest: Mind if I take a look at your cron'ed svn backup script? *** SachaS has quit IRC *** wendall911 has joined #gnuenterprise derek: look at the gnue-packages/finance/gl/classes/gl.gcd it was an old format to describe a bit of gnue-package correct but it was my understanding we obsoleted these sure my question was, what will be the new format? i guess i would ask why did we obsolete (and why are we ressurecting)? when i look at the file you just pointed me to i ask why? i have tables representing all those classes already in my existing 2 tier application i have .gsd files that represent that data so what do i need the gcd for? mybe it's hard to write and hard to parse * derek isnt saying it isnt needed, but rather asking "why" so let me get this straight because it is hard to write an xml schema file we want ANOTHER format? wouldnt it be easier to write a tool (like plugin for designer) to write to our gsd format rather than start another format? i understand (and was a proponent of gcd (human readable) some time back before i get flamed again by reinhard i highly agrre with that however, i think i am of the mind set that xml is readable enough i.e. as long as the format is human editable... i do not think it needs to be massively readable as good tools should do the work but we should still be able to open emacs/vi and tweak if we so desire i'm proposing to extent the existing gsd for handle package, module info also it would not be hard to write a tool that went from xml to pretty format and pretty format to xml if someone was hell bent on making a pretty format btami: now that might make sense :) like in fact, im almost thinking that jcater had added somethign like that im against the class / propert notation personally :) but that is terminology as the tables are already defined dsmith: go ahead also there are imports within gsd specification so you could do i don't think anything on ash is hidden to anyone w/ an account *** wendall911 has left #gnuenterprise or whatever as one thing we had been doing in packages for 2 tier is makign each table (class) its own gsd file yes, agree then making a master gsd file at the Module level that just imported the tables it needed so if someoen wanted contact manager but not general ledger they only got the appropriate tables (classes) but we were able to reuse say the address table (class) for both vendor and contact manager again im not opposed to gcd directly and what needs to be done needs to be done... certainly i know very little about appserver so it is hard for me to make decisions or form opinions (i.e. take it with a grain of salt) i am just asking questions jamest: No, I don't have an account on ash. ok, i think all these are doable with a little work on gnue common's schema (gsd) part what i don't know too if another xml format (gcd) needed or not koz in appserver there are procedures too so some more tags needed sigh i think some irc meeting would be good to discuss this with core peop well in 2 tier you have triggers and triggers can be .py files that get included so part of me wonders if we need a whole specification for "business rule stuff or not" that is where GCD probably is valid but you are right it needs discussion as i dont think making gsd's support business logic definitions is a good idea maybe the right thing is gcd's *** kilo has joined #gnuenterprise and gcd's can import gsd's yes good point this way module and trigger info is defined for n-tier only but you dont have to "redine" your data structures when doing 2 vs n tier as the gsd would be portable if that makes sense (maybe there are inherent problems doing so), but its an idea i thik it's a good idea * btami hopes jcater/jamest/reinhard read these... *** dhill1 has joined #gnuenterprise bbl *** btami_away has quit IRC *** johannesV_ has quit IRC *** johannesV has joined #gnuenterprise *** dsmith has quit IRC *** dsmith has joined #gnuenterprise *** reinhard_ has joined #gnuenterprise *** bluesbaron_ has left #gnuenterprise *** reinhard has quit IRC can somebody please help me with my English? What is correct: The general assembly was on May 15. r or The general assembly was at May 15. first one thanks usually, "on" is for a date "at" is a time like