*scroll* *scroll**scroll* interesting conversation someon, we're similar to you except i'm the only i.t. guy budget wise, yeah theres no way anyone here would cough up 35k i was thinking of starting a consortium of some sort.... or shopping the idea around spreadk 300k among 300 companies, and all of a sudden you have something gnue really does fill a lot of spaces in between homebrew stuff and things like peoplesoft, its doable providing enough players are there and really, it is the open source way, spread cost and risk around to the point where it doesnt matter also with 300 companies, raising 600k or even 900k would not be difficult holycow: agreed and those sorts of expenses are mostly writeoffs anyway, roi's are not even questioned holycow (~rtaylor@24.86.227.162) got netsplit. chillywilly (~danielb@CPE-24-167-201-211.wi.rr.com) got netsplit. jamest (~jamest@gw.math.ksu.edu) got netsplit. wendall911 (~wendallc@wendallc.icehouse.net) got netsplit. nickr (nick@e-64-35-146-235.empnet.net) got netsplit. Vee (~mike@66.182.192.34) got netsplit. Vee2d2 (~vin@c66.169.136.41.ts46v-07.ftwrth.tx.charter.com) got netsplit. ajmitch (~ajmitch@pop11-port95.jetstart.maxnet.co.nz) got netsplit. thierry (~thierry@AStrasbourg-251-1-1-7.w82-127.abo.wanadoo.fr) got netsplit. someon (~some1@h24-81-151-173.vf.shawcable.net) got netsplit. havoc (~havoc@CPE-65-31-107-254.wi.rr.com) got netsplit. dneighbo (~dneighbo@ip68-109-180-32.ph.ph.cox.net) got netsplit. Stoke (~stoker@dpvc-141-149-254-50.buff.east.verizon.net) got netsplit. wendall911 (~wendallc@wendallc.icehouse.net) returned to #gnuenterprise. chillywilly (~danielb@CPE-24-167-201-211.wi.rr.com) returned to #gnuenterprise. someon (~some1@h24-81-151-173.vf.shawcable.net) returned to #gnuenterprise. holycow (~rtaylor@24.86.227.162) returned to #gnuenterprise. thierry (~thierry@AStrasbourg-251-1-1-7.w82-127.abo.wanadoo.fr) returned to #gnuenterprise. jamest (~jamest@gw.math.ksu.edu) returned to #gnuenterprise. dneighbo (~dneighbo@ip68-109-180-32.ph.ph.cox.net) returned to #gnuenterprise. nickr (nick@e-64-35-146-235.empnet.net) returned to #gnuenterprise. havoc (~havoc@CPE-65-31-107-254.wi.rr.com) returned to #gnuenterprise. ajmitch (~ajmitch@pop11-port95.jetstart.maxnet.co.nz) returned to #gnuenterprise. Vee2d2 (~vin@c66.169.136.41.ts46v-07.ftwrth.tx.charter.com) returned to #gnuenterprise. Stoke (~stoker@dpvc-141-149-254-50.buff.east.verizon.net) returned to #gnuenterprise. Vee (~mike@66.182.192.34) returned to #gnuenterprise. the savings you get, plus the public good you generate could be an astounding proposition Yup, but the problem (as I see it) is finding 300 or so companies that are interested in GNUe as a product. someon, i don't albeit, i don't think it would be either easy nor quick 300 is not a lot companies our size spend 1k without blinking our phone bill here is 5k a month i agree though, gnue would need to fill a need have we considered a non profit deal also? holycow: and others just out of curiosity I think that if 35K could polish the UI and AppServer to a point similar to: http://www.remedy.com/customers/dev_community/images/T&T%20Nov%2002/11-18-2.gif then I could business case it, and get the $$ flowing somewhere... im interested in what people will pay holycow: you have to also remember that every middle management person is an IT expert in their own minds. It may never work. basically i think i can come up with the funding i.e. large shop is willing to pay to polish up GNU Enterprise for their own use Nick change: dneighbo -> derek wendall911, you are correct, it would suffer from group think, again i'm just throwing ideas around same here. basically the thought is they spin off an IT company pay that company to polish and revamp their ERP dneighbo *nod* i may have a few contacts, albeit they are canadian so you can chop value of donation by 1/4 to the us dollar :) er polish GNUe but then they are thinking it would be additional revenue and provide consulting services? another problem is that they want something right away...telling them it will be a year out and they start loosing attention as that the IT company could provide install / support services to people doing installs derek *nod* taht would be of interest to us Action: derek is stating that i think the money part i can tackle we have no problem paying for something that brings in value *nod* the question becomes is there truly a market for the services (product) i am also thinking that we can start a not for profit group and ask for donations from companies That was the case with the 10 companies I spoke with, they all own one IT company as a business venture, but even then, if what they wanted couldn't be done in three months, they wouldn't do it we are a non profit already Same over here, but Co is very limited in what we are allowed to do. 500 - $1000 as a tax writeoff? oh you are? :) FSF sweet GNUe is part of the Free Software Foundation i didnt know that you can donate money to us right now 501c3 tax deductable *nod* sounds like you need someone hitting the streets then write it to Free Software Foundation and earmark it for "GNU Enterprise" i think you are missing my other point i have a company willing to fund the project *nod* i'm listening :) just thinking some broad strokes here currently its just not at the top of the todo list mostly because they have something that is 80% working for them if however they KNEW there was a market drooling derek, your proposition sounds ideal imho it would move to the top of the TODO list that is the incentive would be monetary instead of just luxury of them getting better system our latest assessment is that the gtk2 driver of forms could probably use a little bit of work mostly the addition of a listbox (grid) and it would be close that sounds like its research they would haveto do however, my perspective simply offers the particapants a low cost alternative, i'm not sure i'm qualified to help in market research for a business plan on the idea we still need to audit tand re-evaluate the changes in appserver Yeah... there is no question gnue offers a new service based opportunity however oh well more to come hopefully in a few weeks infact once i'm done with some of our stuff i plan on looking at it here in canada for sure derek: my research results were similar i know i fit it nicely into a niche i even have a need for it for us for a unique set of apps right there derek: listbox shouldn't be *too* hard to add to gtk2 driver, if there's support in the rest of the forms code? derek: what is the range they are looking to spend, and expected time frame? no there is not support elsewhere BUT i dont think ti will be that hard wendall911: they are willing to spend 3.0 full time programming positions for a year or more I've had the immense joy of spending a fair bit of time with python & gtk2 lately :) also they have dedicated data center at disposal derek: that's what it would take, very cool :) derek, appearently you have discussed the idea with them? Action: derek notes they already host gnu enterprise servers at that data center location if they are in the right market segments, why dont they tap their channels and see what incentive they have right on their doorstep? they have that is why they are eager to do it :) its very easy to build out from there really? and the results? oh you mean this isn't theoretical? :) derek, you are a god at this point i think it is not a matter of if (as they are committing best i can tell) it is a matter of when they are still expanding normal operations that is astounding :) Action: someon had a theoretical/ hypothetical funding source and so havent had time i wish i was in that boat my self i could create a ton of value by creating os based solutions for clients So does one have to sign the FSF Copywrite assignment to contribute forms / GNUe based Apps? someon: yes well let me rephrase that that would be to gnue proper i presume if you contribute to the framework (tools) in svn yes you need assignment one could gpl them outside of the distribution trunk i presume Not contributing to gnue-forms, but rather gfd files. if you contribute to gnue-sb or gnue-proper in svn you need assignment if you want to write your own applications with the framework, no you dont yes to both of you :) well derek, thats some astounding news if i may say so, huge boost to the project well i am hoping so it will mean some pain but could be really great as well also one could think of it is getting out there and being ahead of the pack once your company owns its niche no one can really come in and take it away and someone is eventually going to do this spreading the r&d over a large clientbase yields far greater value for the client than the proprietary model where you solve one problem and resell it to all each and every time once clients are onboard for the service and maintenance based part plus customization they aren't leaving with the savings at hand one could theoretically put together a recurring revenue model which really what i.t. companies strive for over the long term once the boom is over Action: someon thinks .oO( 15% x 50,000 licencing for proprietary ERP = 7500 annual maintenance) yip *nod* because the upfront licencing fees are not there and r&d is spread out over all customers you could make that even more attractive and flexible too depending on the clients needs hopefully by this time next year we will be able to say how well it works :) and still make good margin i'm sure i do a lot of govt work lookin forward to it derek :) im getting a lot of collaboration opportunities there is a very real chance we do govt work as well that a budget system for a MAJOR government could be done in gnueu there are some unique opportunities here Has anyone put GNUe -> PosgreSQL -> Replication derek i would be very interested depends on assessment of maturity rate goes do you mind me asking what counry? <-- canada here And could an AppServer be set up to contact the Replicated copy of the DB in the event the primary was unavailable? as the time line will be short so wont have the time to invest in framework (only the app) someon: we are looking HARD at postgres replication features as we speak HA-GNUe would be amasing! *nod* holycow: im in southwest united states (arizona specifically) oh excellent your solution would translate well here also for govt? well i'm talking in principal, our countries are fairly similar that it wouldn't be hard to consider perhaps offering similar service here, where applicable translating an app meant for the chinese system of doing things might be a whole other story :) tranlating process wise i mean IS there any way that the same form could have different labels depending on the language? currenly i am not sure arturas was workign on it or we were talkign about it long term absolutely Just thinking that might be a better way of dealing with translations i just had a thought, if oracle and peoplesoft can convince people to pay those amazing prices for their product... theres no way gnue cannot *hmmm* theres just no way you couldn't make money with it if one had their sales expertice and experienced dev team Does GNUe/PosgreSQL do case-insensitive searching? PeopleSoft/Oracle doesn't, without an option licence... more $$$$ heh If GNUe can provide a better product for a lower price, it should be an EASY sell someon: i think we have an option in there Charge a 5% maintenance fee (all newer GNUe engines in the year on CD) to your consulting clients, and you should be able to develop a positive cash flow i like that yes + consulting at x/hr for custom work and the client is getting exactly what they need *nod* well im in firm belief the product doesnt evne have to be AS good it just has to be close Also, when running gnue-reports, could it run against a second database (ie. so operations DB doesn't get slowed down) not saying we wont strive for better derek, thats more what i was hinting but its SOOOO bad out there right now that something close without the "baggage" is incentive enough as evidenced by GNU/Linux desktop acceptance i've seen oracle sales completely oversell them selves in a lot of places and open office acceptance at oracle prices you really are pushing heavily on the bs meter relative to the needs of most organizations in the marketplace without baggage heh you got that right Reports dumps to a /tmp csv file, and then calls "oocalc file" as an option... i'm converting our entire company to open office and debian desktops having that aleviate us track our ms licencing alone makes it worthwhile for us, never mind the thousands of extra free apps and tools you get On the reports idea... GNUe -> DB -> ReplicatedDB <- Reports dneighbo (~dneighbo@ip68-109-180-32.ph.ph.cox.net) joined #gnuenterprise. wendall911 (~wendallc@wendallc.icehouse.net) left irc: "Download Gaim: http://gaim.sourceforge.net/" derek (~dneighbo@ip68-109-180-32.ph.ph.cox.net) left irc: Read error: 110 (Connection timed out) sjc (~sjc@cpc2-seve3-4-0-cust112.popl.cable.ntl.com) joined #gnuenterprise. johannesV (~johannes@M1554P031.adsl.highway.telekom.at) joined #gnuenterprise. reinhard (~reinhard@M1250P006.adsl.highway.telekom.at) joined #gnuenterprise. someon (~some1@h24-81-151-173.vf.shawcable.net) left irc: Remote closed the connection reinhard: geasInstance.py - Line 76: all numbers are converted into "float", because a string cannot ever matches 0 (but only '0') scale = propertydef.gnue_scale if len (scale) == 0 or int (scale) == 0: would be better -- i think please correct me if i'm wrong this replacement would match an empty scale-string as well as one with '0' siesel (~jan@61-216-92-204.HINET-IP.hinet.net) joined #gnuenterprise. morning good morning siesel johannesV: propertydef.gnue_scale is an integer at least that was my understanding hmm, it should but if you add a 'type (propertydef.gnue_scale)' before there comes a '' :) i was wondering why i got all those numbers like 35.0, 10.0, 0.0 ... well, actually they were all 'float'-types (length, scale) ah, ok ... you found it? have to check the classrep once more ... or even the language interface ah well yes the classrep because it's preloaded yes ... i had the same idea ... this must be wrong in the boot-catalogue ... i'll check it IMHO it could be connected with the database as many integers (in the db) get passed on as floats by the dbdriver. siesel: we are talking about frontend <-> appserver, not the other way around not appserver <-> db i mean yes, but that doesn't mean, that gnue-scale's original value comes from the database. I' mean, doesn't come from the database but that's just my 2cents. siesel: you're right siesel: the case we are talking here is a special case the problem is probably in the inital catalog of preloaded class repository information (from classrep.ini) *normally* we get gnue_scale from the db of course ok so, after booting the classrepository from the repository.ini they're all of type string after running the initial reload of the module- and class-dicts they're all floats, because of the conversion-handling i described above to fix this situation we have to make an initial conversion on booting from the repository.ini or am i wrong ? i think you're right Action: johannesV getting some coffee this initial conversion must even be hardcoded like if fieldname in ['gnue_length', 'gnue_scale']: value = int (value) etc. reinhard: why not do it via multiple try: except: yeah, cause we have no type information, but i'd do a try:except ... to make ints and floats siesel: just thought the same :) the only problem would be, that a wrong repository.ini would create not only value, but also type errors,... but that IMHO isn't so important hmmm i don't like that so much but i leave it up to you, johannesV another option would be to store these type information in repository.ini too. i'm ok with everything that works basically we have (IIRC) gnue_length and gnue_scale as integers and the rest as strings so acutally the 2 lines if fieldname in ['gnue_length', 'gnue_scale']: value = int (value) should do the job perfectly reinhard: that's right .. (of course exchange "fieldname" and "value" with the correct variable names ) reinhard: is gnue_length and gnue_scale hardcoded in other parts of the class repository? i think i'll do it this way for the moment but we could think about replacing repository.ini by kind of a gsd in some future :) yes. that would be the best solution. siesel: it is of course hardcoded in other parts of appserver ok, it's fixed .. i did it in BaseObject's constructor, when loading the predefined attributes reinhard: then IMHO it's ok to hardcode it again. We just shouldn't do it with too much other fieldnames sjc (~sjc@cpc2-seve3-4-0-cust112.popl.cable.ntl.com) left irc: "working" reinhard: the gsd file is correctly encoded in utf-8 cool reinhard: I've looked at the wrong property :( hehe so I'll change the dumpXML as we've talked about that's bad when you look for a bug that isn't there at all yes right :) so you have to change dumpXML? when the file is correctly encoded already? well, actually dumpXML() tries to make a "unicode (value, gConfig(textEncoding))" where textEncoding defaults to Latin1 here (from locale i think) but value is utf-8 encoded ah ok so this leads to the decoding error thus the decoding error yeah by adding a parameter which describes the input-encoding we should resolve this problem yeah the output is always utf-8? oh well you said before, yes :) johannesV: textEncoding default to iso8859-1 and is defined in gnue.conf it should normally be the locale encoding, but it isn't set automatically to it. siesel: ok, but i want to use that encoding in my gnue-* apps, only the gsd file should be created with utf-8 the problem is that xml reading/writing isn't unicode enabled at the moment. kilo (~kilo@ip102-205.ktv.tiszanet.hu) joined #gnuenterprise. as I understand dumpXML it creates an xmlfile encoded as UnicodeType (string), so to write utf-8 it has to be encoded again. siesel: how dows UnicodeType look in a file? but that doesn't have to do with textEncoding, which is just needed to transform the unicode which are passed from/to the xml reader/writer into the GObject values siesel: imho, a file always has an encoding reinhard: I think it would be a two byte encoding (or even 4 byte) possibly it would use the default locale encoding. i.e. not utf-8. appearently, this is not the case :) the 2 byte encoding i mean yes. so it will be locale = iso8859-1 != utf-8 johannesV will have to check that I finally understand how dumpXML works. So I'll fix this and have to fix some other XML creation stuff in the designer code base. siesel: ok, so I'll revert my changes .. siesel: how will the xml output be? will it be current locale or will it be utf-8? IMHO it should be utf-8 so that gsd and gfd files can be exchanged regardless of locale reinhard: I agree on that best is utf-8, as it allows to encode characters which aren't in the current locale siesel: ok, i agree and xml is encoded in utf-8 if no encoding is set in the header Generating schema definition ... DB000: Error: ASCII decoding error: ordinal not in range(128) so we still have to add a parameter to specify the source encoding, right? where is that error? siesel: well or we remove the unicode () ... from dumpXML GObject.py unicode (val, gConfig ('textEncoding')) ... val is not encoded in textEncoding but utf-8 removing the unicode means, that we have to move to unicode in the whole codebase (in our case) ok, what about setting textEncoding to utf-8 for gnue-schema ? so if we won't remove the unicode () from dumpXML we have to add a way of declaring the values encoding i'd say we add an optional parameter to dumpXML for the source encoding if the parameter isn't passed, it defaults to gConfig('textEncoding') siesel: how would i change the textEncoding 'only for gnue-schema' ? other possibility could be to put Unicode instead of String values in the GObject's when the tree is built johannesV: [gnue-schema] textEncoding=utf-8 well ok, in the config-file ... but i don't like that, because it means to have an option in the config file that may not be changed and makes no sense to change best way IMHO would be the additional parameter reinhard: the last choice would raise TypeErrors. The first one is ok. I would like to replace gConfig('textEncoding') with a variable "textEncoding" which is passed to the procedure and has the default value "gConfig(textEncoding)" setting the variable in the config file doesn't work, as the schema stuff doesn't declare its own section siesel: that's exactly what i meant well it could (just have tested it) but it makes no sense as reinhard has mentioned before so we acutally agree about the new parameter ok, has anyone implemented it yet? :) no, i've reverted it .. this parameter also needs to be added to loadXML ... or the like probably if that does a conversion now if it doesn't convert anyway, then it's ok, because that's what we actually want reinhard: it does a conversion. or it had done. I removed it in a private tree, and are not shure if I commited the change. I'll look into it later today. siesel (~jan@61-216-92-204.HINET-IP.hinet.net) left irc: "later" dimas (~ds@195.218.177.46) joined #gnuenterprise. kilo (~kilo@ip102-205.ktv.tiszanet.hu) left irc: Remote closed the connection kilo (~kilo@ip102-205.ktv.tiszanet.hu) joined #gnuenterprise. btami (~btami@ip102-205.ktv.tiszanet.hu) joined #gnuenterprise. thierry_ (~thierry@AStrasbourg-251-1-1-7.w82-127.abo.wanadoo.fr) joined #gnuenterprise. thierry (~thierry@AStrasbourg-251-1-1-7.w82-127.abo.wanadoo.fr) left irc: Read error: 110 (Connection timed out) Nick change: thierry_ -> thierry Nick change: reinhard -> rm-lunch btami (~btami@ip102-205.ktv.tiszanet.hu) left irc: Remote closed the connection Nick change: rm-lunch -> reinhard holycow (~rtaylor@24.86.227.162) left irc: "Leaving" dsmith (dwmjy606uu@oh-strongsvillecadent1-1f-100.clvhoh.adelphia.net) joined #gnuenterprise. Action: kilo kicks wx. and again. and again.and again.again.again.again.again... lxf (~agus_tea@202.73.120.151) joined #gnuenterprise. kilo (~kilo@ip102-205.ktv.tiszanet.hu) left irc: "Leaving" wendall911 (~wendallc@wendallc.icehouse.net) joined #gnuenterprise. wendall911 (~wendallc@wendallc.icehouse.net) left irc: Read error: 54 (Connection reset by peer) wendall911 (~wendallc@wendallc.icehouse.net) joined #gnuenterprise. lxf (~agus_tea@202.73.120.151) left irc: Client Quit jbailey (~jbailey@dragonfly.fundserv.com) joined #gnuenterprise. bbl reinhard (~reinhard@M1250P006.adsl.highway.telekom.at) left irc: "'Hardware' defines as the parts of a computer system that can be kicked." bernanner (~bsofko@alb-24-194-28-89.nycap.rr.com) joined #gnuenterprise. bernanner (~bsofko@alb-24-194-28-89.nycap.rr.com) left #gnuenterprise. sjc (~sjc@cpc2-seve3-4-0-cust112.popl.cable.ntl.com) joined #gnuenterprise. reinhard (~reinhard@M1250P006.adsl.highway.telekom.at) joined #gnuenterprise. jcater (~jason@w202.z065105010.mem-tn.dsl.cnc.net) joined #gnuenterprise. chillywilly (~danielb@CPE-24-167-201-211.wi.rr.com) left irc: Read error: 60 (Operation timed out) siesel (~jan@61-216-92-204.HINET-IP.hinet.net) joined #gnuenterprise. hi siesel hi reinhard seems like johannesV has sorted out all encoding/decoing issues yes, I saw the commit some minutes ago. so instead of the loadXML issue some comments: 1. xml files have the standart encoding 'utf-8' so it doesn't have to provided extra. and gsd files encoded as iso8859-1 will still work, as the encoding is handled by the parser and unicode is parsed in what i would beg you to do (if you have time) was to test with your forms and your test cases (with chinese characters and such) siesel: correct but 2,3,4,5.. I fear that the change is a bit intrusive and it isn't the right time do it siesel: writing "encoding=utf-8" doesn't hurt and makes things a lot clearer which part of the change? GTypecast I'll check it again. But its difficult to check, when many different changes are in one changeset. the change in GTypecast is not intrusive at all wendall911 (~wendallc@wendallc.icehouse.net) left #gnuenterprise. because when the value contained a non-ascii character before wendall911 (~wendallc@wendallc.icehouse.net) joined #gnuenterprise. the "text", "name" and "uppername" generated a traceback now it runs through str(x) does a traceback when x is of type Unicode and contains non-ascii characters one second. reading it the second time as a general impression, i think common should use Unicode type variables much more often instead of String type variables and in any case it should be better documented whether a function expects a parameter to be Unicode or to be String. i wonder if there is some easy way to check types of parameters like def foo (x, y, z) checktype (x, UnicodeType) checktype (y, StringType) checktype (z, [StringType, None]) or something to that effect more readable than if not x is UnicodeType: raise Exception if not y is StringType: raise Exception etc. ok. one the second view the patch looks much less intrusive than before. cool :) still I have some issues with it. reinhard: you're right. functions should be defined more clear please share your concerns :) there are two much encode/unicode statements in the code. /two/too/ yes i agree completely that's why i say common should use much more unicode values and less string values the right way to go is to use encode/decode as the last/first step and nowhere else yes exactly but then for example GTypecast would have to return a Unicode instead of a String for text attributes which *would* have been a quite intrusive change... in fact i think it would be highly appreciated if you looked at those issues because as one of the people also knowing forms and reports