Fw: Re: SoC status?

[Ori Bernstein <ori eigenstate org>]

I'm copying the list on the mail I sent to my mentor a little while ago:

---
Anyways, I've been talking with Ryan (desrt) and it looks to me like the way to
go is to use DBus as the scripting engine, since it exposes objects, method
calls, and all that other stuff. It also means that we should be compatible
with KDE4's scripting, since they're replacing DCOP with DBus, although I
haven't found any doucmentation on the exact interfaces (ie, are there any DBus
interfaces I'd need to implement? does it all go on a certain object path? ...)

IMO, the best way to bring this to Gnome is to make sure DBus has good,
painless bindings for the languages in use in Gnome, which means that C really
needs lots of work, in the way of fixing GObject Introspection and writing a
thin DBus binding around that. I'll be working with Rob Taylor on getting those
up to shape, I think.

Eventually, I want scripting an application to be just exposing an object or
two on the bus, something like "dbus_g_expose_object(object, "method1",
"method2", ...);", with the martialling and so on done automatically from
introspection information.

> Thanks.

No problem.
Sorry about not updating you more often. Anyways, at the bottom of the mail,
I've attached the discussion I had with Rob.

> Hub


< robtaylor> Ori: just trying to give you an overview of the state of play :)
-!- Mithenks [~mith host136-255 pool8251 interbusiness it] has joined #gtk+
< Ori> robtaylor: oh, ok.
< Ori> robtaylor: what me and desrt were mainly discussing was how to get the
actual data into the binary 
< robtaylor> Ori: did you read metadata-format.txt
from gobject-introspection? 
< robtaylor> Ori: its a bit heavy to work though,
but worth ir before doing too much planning, as its pretty right imho 
< Ori> yep.
< robtaylor> Ori: but yeah, at the moment there's not much there on the
interface to the data, and desrt has a point about not having to dlsym lookup 
< Ori> robtaylor: yeah. being able to avoid doing relocations to get functions
would be good. 
< robtaylor> Ori: well in the current blob format there's no
relocs at all 
< Ori> true. 
< robtaylor> Ori: but it stores symbol names, which
need dlsym lookups 
< Ori> yeah. 
< robtaylor> Ori: i chatted a bit with mathrick
about that a while back, and he mentioned something about dynamic languages not
having to load the dso to do an inport 
< robtaylor> Ori: but i don't really see the sense in that myself 
< Ori> robtaylor: yeah. if you want to use the dso in a dynamic language, you're
loading it anyways. 
< robtaylor> yep 
< robtaylor> Ori: so my current plan of attack is code-parser -> update blob
generator -> sensible api to introspect a given interface/type/object/etc 
< Ori> yep. 
< Ori> and then on top of that, you do a dbus-glib binding, which can be really
simple. 
< robtaylor> Ori: so if you want to work on this, we should probably split that
up a bit :) 
< robtaylor> oh yes indeed 
< robtaylor> writing the (de)marshalling to be fast would be a nice task 
< robtaylor> it'll all need rewriting anyhow, and i'd be tempted to just write
the wire mesg directly and not botherusing the libdbus message parsing/writing
stuff < Ori> yeah. 
< robtaylor> Ori: as you can see, its rather a big task, which is why i
wouldn't have reccomended it for SoC ;) 
< robtaylor> *all together 
< Ori> hehe. I didn't know what I was picking when I chose this for SoC 
< Ori> I thought I was going for something fairly easy =P 
< robtaylor> Ori: oh, how wrong you were =) 
< Ori> well, I guess it's a good thing that funding was rejected at the last
minute for the summer job I planed to have 
< robtaylor> Ori: you're an MSc right? 
< Ori> MSc?
< Ori> define?
< robtaylor> Ori: masters student?
< Ori> ah, nope.
< Ori> undergrad, engineering physics
< Ori> minoring in CS
< robtaylor> ah, you're really jumping in the deep end here then,i guess =)
< Ori> best way to learn =P
< robtaylor> cool
< Ori> robtaylor: mm, did desrt talk about the conclusions from experiments
done yesterday? < robtaylor> Ori: nope
< Ori> ah, ok
< Ori> essentially, the difference between symbol addresses isn't a
compile-time constant, only a link-time constant < Ori> so if you want to
inline it into the blob, you'll have to modify the .so file < Ori> (if you want
to refer to the symbol directly) 
< Ori> (...well, semidirectly. __magic_evil_symbol + offset) 
< robtaylor> Ori: not sure i understand 
< Ori> robtaylor: to avoid relocations, you can't just save the function's
address 
< Ori> so you can store a difference between the function's address and
a magic symbol (eg: the blob's location) 
< Ori> but you can't know this until after the linker does it's job, because
the functions can live in different sections, come from different .o files, ...
< robtaylor> Ori: ah, yes. you might be able to do some linker script magic
though 
< Ori> yeah, or rewrite the .so file after, maybe. 
< Ori> g-imbue-with-magic foo.so 
< Ori> or more likely: 
< Ori> g-imbue-with-magic foo.so foo.idl -
< d42>
< robtaylor> Ori: linker script is more
sane =) 
< robtaylor> Ori: anyhow, imho, thats the kind of optimisation to look at much
later down the pat 
< Ori> mhm. 
< robtaylor> *path 
< Ori> well, having an idea of it affects the design somewhat. 
< robtaylor> Ori: not really 
< Ori> robtaylor: ok. well, anyways. first step is probably extracting the
metadata from the objects? 
< robtaylor> Ori: yeah, so i'mworking on that right now < Ori> ok, any pointers
on where I should start hacking? 
< robtaylor> Ori: I don't think its a very parallelisable task, so maybe you'd
like to take on one of the other parts i mentioned? 
< Ori> ok, blob generator, I guess. 
< Ori> did you give me a link? 
< robtaylor> Ori: well, thats actually mostly done. the task there is ficing up
if i find i need to =change the xml format 
<robtaylor> Ori: http://svn.gnome.org/viewcvs/gobject-introspection/trunk/ 
<Ori> robtaylor: ok. so where should I start hacking? 
< robtaylor> Ori: api for intrsospection and dbus bindings, i guess =) 
< robtaylor> I just realised i didn't really leave you much choice =) 
< Ori> yep. 
< robtaylor> Ori: alternatively you could pick up from where i'm at
with the code scanning bit 
< robtaylor> thats a pretty interesting task though, i'd do them in parallel,
so what you need for the bindings helps inform your api choices 
< robtaylor> Ori: what do you think you'dfind most interesting? 
< Ori> I don't know -- I'm still figuring out what the state is. 
< Ori> I guess I'll start with the API, since you seem to have the scanner
covered right now 
< robtaylor> Ori: sounds good. you should probably take a while to orient
yourself and chat it over with your mentor 
< Ori> robtaylor: will do. 
< robtaylor> Ori: feel free to fire me any questions you have