*** dimas has joined #gnuenterprise
*** btami has joined #gnuenterprise
*** kilo has joined #gnuenterprise
*** johannesV has joined #gnuenterprise
<johannesV> good morning
<btami> good morning
<kilo> good morning
*** reinhard has joined #gnuenterprise
<johannesV> the last days i've thought about a logo or an icon for gnue but i had no good idea
<johannesV> and as i was thinking about icons and the like i thougth we have no chance to set an individual icon for a forms-application
<johannesV> or do we ?
<johannesV> so if one creates 5 forms (gfd's) they all have the same icon
<kilo> maybe create a new property for the form?
<johannesV> yeah, which should hold an URL pointing to the icon
<btami> i think one gnue icon is enough for all gnue, at least for me :)
<johannesV> well, if i create two apps using gnue (like a cd database app and an address book) it'd be fine to give them different icons
<kilo> i agree with johannesV
<btami> yes
<btami> so one icon for one app, but
<johannesV> ok, then another problem is the kind of icon to set (like an .ico for MSW and a xpm for GTK ...)
<btami> not for one form
<johannesV> btami, that's right ... i think all forms of the same "top-level"-form should have the same then
<kilo> that's fine imho
<btami> ok
<kilo> no need to overuse it
<johannesV> ok, so wrt a logo for gnue ...
<johannesV> what do you associate with gnue ?
<btami> a gnu with some money :)
<johannesV> ok
<johannesV> what else ? only money ... ? :))
<kilo> whisky?
<johannesV> *lol*
<btami> but that goat was nice too...
<btami> dunno
<kilo> so we need a big fat ugly rich gnu with a bottle in hand
<reinhard> a citicen kane type of gnue?
<reinhard> err gnu
<johannesV> hm
<reinhard> erm
<reinhard> actually, did I say good morning already?
<reinhard> no?
<reinhard> good morning all
<reinhard> :-)
<btami> have we have to use an animal at all?
<johannesV> no we don't have to
<johannesV> how would you visualize the word "enterprise" ?
<johannesV> a company ? a network ? people, money ... ?
<kilo> some unrecognizable object in some network
<johannesV> what about a picture of the starship enterprise, replacing "NCC 1701-E" with "GNU" ?
<johannesV> j/k
<johannesV> :)
<kilo> oh no then we all have to put strange metallic thingies on our foreheads?
<reinhard> ah well
<reinhard> our captain jamest kirk....
<johannesV> right
<johannesV> :)
*** johannesV has quit IRC
*** johannesV has joined #gnuenterprise
*** yure has joined #gnuenterprise
*** johannesV has quit IRC
*** johannesV has joined #gnuenterprise
*** siesel has joined #gnuenterprise
<reinhard> cu all
*** reinhard has quit IRC
*** lekma has joined #gnuenterprise
<lekma> hi all
<lekma> johannesV: you around?
<lekma> playing with new RPC inteface
<lekma> all i get after an open() is {'__rpc_datatype__': 'object', '__id__': '-1216151060'}
<lekma> no login(), logout(), etc.
<lekma> so, is there a way to get a session object using std xmlrpc lib?
<johannesV> lekma, that's actually a session object
<johannesV> lekma, are you using gnue xmlrpc client interface ?
<lekma> johannesV: nope
<johannesV> ah, ok
<lekma> i'm trying to acces from outside gnue
* johannesV phone
<kilo> hi lekma
<johannesV> ok, back
<lekma> hi kilo
<lekma> how are you?
<johannesV> well, lekma, I've introduce the object oriented rpc interface
<kilo> fine thx
<lekma> :)
<johannesV> this means you get an object handle back from open ()
<kilo> and you? any new projects in sight?
<johannesV> gnue's xml rpc client library transforms this into a rpc-proxy class
<lekma> johannesV: hmm i have to look at how the client library does that...
<johannesV> on a call to this proxy - like login () - the proxy class transforms this into an rpc call like call ('login', object-dict)
<johannesV> yeah
<johannesV> that'd surely the best thing you can do
<johannesV> it's not very complicated anyway
<johannesV> :)
<siesel> hi johannes, do you have any desciption about what goes over the wire, except of the client library
<lekma> kilo: i'm fine been busy, but now fully working on my pet project : axul client for appserver
<johannesV> lekma, why don't you use gnue's rpc lib ?
<johannesV> siesel, no i haven't written any docs about
<johannesV> our doc is the code :))
<lekma> johannesV: i'd like to avoid having gnue as a requirement
<lekma> i mean having xulrunner
<johannesV> btw. i've added an implementation for pyro too
<lekma> and pyxpcom
<johannesV> so you're not limited to xmlrpc
<lekma> as requirements is already heavy
<johannesV> lekma, that's ok ... we knwe that we're breaking some code with this change to the oo rpc-interface
<lekma> pyro seems nice
<johannesV> but as it has been in our todo-list for a very long time
<johannesV> siesel, what kind of doc are you missing ?
<johannesV> do you mean a document for 'non-developers' ?
<siesel> no.
<siesel> I just want to spare some time.
<johannesV> ah, ok, sorry ...
<lekma> johannesV: on another topic (i have some catchup to do) what is the state of authentication and generated forms?
<siesel> In the past I created a javascript rpc stub out of the grpc file
<johannesV> lekma, nothing changed regarding authentication
<siesel> but without grpc file anymore ...
<johannesV> siesel, grpc has been removed
<johannesV> lekma, there's still that basic authentication (as this was a topic for a 0.6 release i think ...)
<johannesV> siesel, how is that javascript interface working ?
<siesel> lekma, what kind of client are you writing?
<johannesV> (just in a big picture)
<lekma> xul
<siesel> lekma: cool, that's what I writing currently too.
<lekma> i'd like appserver to handle a kind of template
<lekma> siesel: joining efforts?
<lekma> siesel: i'm trying to use pyxpcom
<siesel> johannes: basicly a precompiled gfd file (to html) access javascript functions and uses xmlrpc to connect to appserver
<lekma> to have native python objects
<siesel> lekma: yep, i would like to
<siesel> lekma: do you mean to share code with base gnue?
<lekma> siesel: i don't know it depends on the gnue people :)
<lekma> but i'm willing to share code with anyone
<lekma> maybe i can sum up what is my status now?
<dimas> as you discuss this on #gnuenterprise, all codebase are belongs to gnue, i suppose :)
<kilo> wow what a nice move it would be...
<siesel> lekma: yes, what is it?
<lekma> dimas: i think it's more of a licence issue, cause xul its friends are all MPL
<lekma> and i don't know if FSF wants to provide code wich is under another licence than GPL
<dimas> understandable
<lekma> so if FSF don't want to include it in gnue we can always provide it separately
<siesel> so you mean, that a firefox extension, or xulrunner application has to be licenses as MPL?
<lekma> but one thing is sure: all i'm writing will be freely available
<lekma> siesel: i'm not sure about it
<lekma> that's my point
<lekma> if you use say the DOM Inspector
<lekma> i know for sure it is MPL
<lekma> so what can be the licence of a product that redistribute DOM Inspector
<lekma> ?
<lekma> back to status: last year we had a project to bring appserver in production with a xul interface
<siesel> ok
<lekma> the soft was working but was not good
<lekma> and the project failed
<lekma> (we had to reimburse the client)
<lekma> so based on last year mistakes i think that what would be really nifty:
<lekma> - that the xul client don't rely to much on javascript
<lekma> - that appserver had a kind of template engine that would dinamically render forms
<lekma> what i have now are say the foundations:
<dimas> there are a lot of separate template engines, is there a need for one more?
<johannesV> what do you think about these images: http://www.gnuenterprise.org/~johannes/gnue-1.png and http://www.gnuenterprise.org/~johannes/gnue-2.png ?
<johannesV> which one do you prefer ?
<lekma> a xulrunner app with python enabled and a few set of extensions that
<siesel> lekma, that would be great.
<kilo> johannesV: 2nd
<kilo> needs more scratch to cover the US though :D
<lekma> johannesV: second
<kilo> maybe a hurricane?
<siesel> But how difficult is it to install python on a standart mozilla / xulrunner installation
<lekma> johannesV: the earth is to detailed i think :)
<johannesV> but this one shows the us ... :)
<lekma> siesel: well there are two things
<lekma> first the original pyxpcom implementation that is now in HEAD branch of mozilla
<lekma> but Mark Hammond (of the famous win32 python exts) is working on a lang agnostic implementation of the dom
<lekma> with python as it's first lang
<lekma> so when this lands (he says in a few weeks) we will have something great
<siesel> that would be cool.
<lekma> which allow to have python script directly in xul files
<lekma> but in the meantime i work with the current impl which allow the use of python components that can be used by javascript
<lekma> i spent a great deal of time sorting out all of the pbs to have a xulrunner build with python cause xul has the same default as gnue, ie: lack of docs!!!
<siesel> yes, i got the same impression
<lekma> siesel: do you run linux or win32
<lekma> ?
<kilo> we *have* docs. stored in johannesV/reinhard...
<siesel> linux and win32
<siesel> and i run the application on firefox
<siesel> what kind of development env do you use?
<lekma> can i send you a 7,5mb archive
<lekma> ?
<siesel> yep.
<lekma> it's what i have done since i restarted (from scratch)
<lekma> i think that you may have to make a symlink to have it work
<lekma> cd /usr/lib/python2.4/config
<siesel> ok, wait a second
<lekma> ln -s /usr/lib/libpython2.4.so
*** btami has quit IRC
<lekma> siesel: it's only the local part, as i hope that we can generate all the rest from appserver
<lekma> (that's what we did last year, but in an inefficient way)
<siesel> where does xchat put its files...
<kilo> ~/.xchat/download...
<johannesV> or .xchat2/downloads
<siesel> yep, version 2
<kilo> well i was sure ye could make that up :D
<lekma> i don't have a place on the net anymore to put such things
<lekma> i nedd a new hosting provider :(
<siesel> ok, I have started it and get a nice looking gui
<lekma> :)
<siesel> can it already connect to appserv?
<lekma> that'all there is to it for the moment
<lekma> i was trying to get a hand on the new rpc stuff
<lekma> what's interesting though (i think) is that everything is extensions
<lekma> you even have extensions of extensions :)
<lekma> so if you think i'm in the rigth direction maybe we can combine efforts
<lekma> but there is a lot to discuss...
<siesel> yes.
<lekma> i hope to have the connection stuff done next week
<lekma> (if i understand it)
<siesel> with which language do make the connection? python or javascript
<lekma> i think python is our best bet
<lekma> we would have native python objects
<siesel> I've connection code and client code almost ready in javascript
<lekma> and i didn't find any xmlrpc library in javascript good enough
<lekma> hmm...
<lekma> do you use your own xmlrpc stuff
<siesel> it has just to been adapted to the new object code
<siesel> I'm using vcXMLRPC.js
<lekma> or do you use nsXmlRpcClient component from mozilla
<lekma> vcXMLRPC gave me a lot of headaches last year
<siesel> what kind of?
<lekma> it has a few bus in treating dates, and long strings
<lekma> but the major headache was the prototyping thing
<lekma> cause it added a lot of cruft to std objects
<lekma> but really i don't know
<lekma> i think we should choose the more efficient approach
<lekma> and i'm a little biased against javascript
<siesel> it's kind of ugly
<lekma> and its handling of asynchronous connections for example
<siesel> my aim is to have a easy to use frontend for appserver, which can be run on as many platforms as possible.
<lekma> siesel: same for me :)
<siesel> In case much installing effort is needed, the original gnue client can be used.
<lekma> but python is common enough now (and cross platform) (and it comes with batteries included)
<siesel> yep. I think if we can install python in firefox as easy as f.e. a flash plugin,... it would be great.
<lekma> well (in theory) you can build pyxpcom as a standalone component http://kb.mozillazine.org/Standalone_PyXPCOM
<siesel> sorry, I have to leave for 1-2 hours
<lekma> but you still need python installed
<siesel> hmmm,
<siesel> ok, in 1-2 hours let talk more ok..
<lekma> ok
<kilo> bbl
*** kilo has left #gnuenterprise
*** jamest has joined #gnuenterprise
<siesel> hi jamest
<jamest> hi
<johannesV> hi jamest
<jamest> hi
*** jcater has quit IRC
*** jcater has joined #gnuenterprise
<siesel> hi jcater
*** btami has joined #gnuenterprise
*** dino4k has joined #gnuenterprise
<siesel> lekma: I had a closer look at your application
<siesel> I'm just getting too tired. let us discuss tomorrow
*** siesel has quit IRC
<lekma> johannesV: i had a look at the gnue xml rpc client driver
<lekma> from what i understand the following should work:
<lekma>     server = xmlrpclib.ServerProxy("http://192.168.123.3:8765")
<lekma>     sessobj = server.open({"_username": "", "_password": "", "_language": "en"})
<lekma>     print sessobj
<lekma>     print server._call(sessobj , "login", ({"_username": "", "_password": ""}))
<lekma> but i get an ObjectNotFoundError
<lekma> ObjectNotFoundError: Element of type \'object\' with id \'-1216303284\' not found in store\n'
*** klasstek has joined #gnuenterprise
<johannesV> lekma, and sessobj is a dict having __type__ and __id__ in it ?
<lekma> yes
<johannesV> lekma, what if you use server.call (sessobj, "login", (...))
<lekma> {'__rpc_datatype__': 'object', '__id__': '-1215895028'}
<johannesV> cause this would automagically call the typeconf.rpc_to_python for all args
<johannesV> as well as changes sessobj into self on the serverside
<lekma> not __type__ but __rpc_datatype__
<johannesV> yeah
<johannesV> that's ok
<lekma> there is no call method available, is there?
<johannesV> of course it should be
<lekma> ['_call', '_destroy', 'getFilters', 'open', 'system.listMethods', 'system.methodHelp', 'system.methodSignature', 'updateRepository']
<lekma> that's the result of server.system.listMethods()
<johannesV> ah, ok
<johannesV> that's correct ...
<johannesV> hmm
<johannesV> but in _call () the storedObject argument is already a python-object (as identified by the object-id-dict
<johannesV> )
<johannesV> so, maybe we'd have to publish call () as well
<johannesV> no
<lekma> what would be the client in call?
<johannesV> actually that should work ... as the wrapping should be done internally
<johannesV> lekma, have you tried using call instead of _call
<lekma> i'm afraid it's more to do with the xmlrpclib
<lekma> yes, same error
<johannesV> hmm, actually it should work with the _call, as the clientadapter just calls the same
<lekma> johannesV: is the session object removed from the store as soon as the conncetion is "closed" (in the http sense)?
<johannesV> ah
<johannesV> you're not using persistent connections ?
<lekma> it seems std xmlrpclib uses HTTP/1.0
<lekma> so i'd say no
<johannesV> if you look at gnue.common.rpc.drivers.xmlrpc.ClientAdapter ....
<johannesV> there i've created a class implementing persistent http connection
<lekma> yes i've seen it and wondered why
<johannesV> so we don't have to create a new http connection per rpc request
<johannesV> which is a big drawback on performance
<lekma> ok
<johannesV> ah, and aside from that there's a bug in the python lib somewhere ... (don't remember exactly)
*** jcater has left #gnuenterprise
<johannesV> so i just did a fix for us there ...
<lekma> hmm... so i'm in need of an xmlrpc lib that does it's connection using HTTP/1.1...
<lekma> :)
<nickr>  /win 11
<nickr> woops
<johannesV> yep
<johannesV> lekma, it's not that hard to accomplish; ie. you could copy from ClientAdapter
<lekma> johannesV: :)
<lekma> bbl
*** derek has quit IRC
*** sjc has joined #gnuenterprise
*** derek has joined #gnuenterprise
*** jcater has joined #gnuenterprise
*** reinhard has joined #gnuenterprise
<lekma> johannesV: still around?
<lekma> johannesV: i can connect!!! great
<lekma> there's still smthing that bothers me;
<lekma> server._call(sessobj , "login", "hacker", "secret") works
<lekma> but shouldn't it be server._call(sessobj , "login", ("hacker", "secret"))
<lekma> or server._call(sessobj , "login", ["hacker", "secret"])
<reinhard> no
<reinhard> first parameter is object, second parameter is method name, 3rd to nth parameter are 1st to n-2th parameter of the function
<reinhard> btw
<reinhard> good to see you back on gnue
<reinhard> and excellent to see you and siesel joining forces
<lekma> :)
<lekma> should i systematically call transport.close() when a session is over? or is this connection reused by other session?
<lekma> another thing _destroy(session) is the counterpart of open, isn't it? why the underscore?
<reinhard> usually _destroy isn't called directly, but it is called implicitly at the time when a client side object dies
<reinhard> (however this is client side implementation specific)
<reinhard> closing the HTTP connection will kill the server side process that was forked for this connection, and will require a new authentication on next connection
<reinhard> so closing the connection should be a very good an safe approach
*** johannesV_ has joined #gnuenterprise
*** johannesV has quit IRC
*** johannesV_ has quit IRC
*** johannesV has joined #gnuenterprise
<johannesV> back
<johannesV> hmm, that setup-cvs.py doesn't install all images under forms/images/default ...
<johannesV> ah, ok, got it workin
*** btami has quit IRC
*** johannesV has quit IRC
*** dino4k has quit IRC
*** yure has quit IRC
*** lekma has quit IRC
*** jamest has left #gnuenterprise
<reinhard> night all
*** reinhard has quit IRC
*** jamest has joined #gnuenterprise
*** jcater has quit IRC
*** derek has quit IRC
*** jamest has left #gnuenterprise
*** jamest has joined #gnuenterprise
*** jamest has left #gnuenterprise
*** jamest has joined #gnuenterprise
*** klasstek has quit IRC
*** sjc has quit IRC
*** derek has joined #gnuenterprise
*** derek has quit IRC
*** derek has joined #gnuenterprise
*** derek has quit IRC