IRC Meeting Log on #berlin

#berlin

	BEGIN LOGGING AT Thu Sep 14 21:39:04 2000
NickElm:	Hello all!
misaka:	Heya Nick.
stefan:	NickElm: hi
NickElm:	;)
	stefan is still chasing bugs :(
NickElm:	stefan: Aww. :(
stefan:	NickElm: on the other hand, if I get that worked out, it will be really clean ;)
NickElm:	stefan: What exactly is the problem? Related to client hangups? I didn't quite get your design list posting.
NickElm:	stefan: :)
stefan:	NickElm: cleanup trouble when the client(s) are killed.
NickElm:	stefan: Yes, all right.
stefan:	NickElm: i.e. 'irregular' exits.
NickElm:	stefan: Having to do with the order of deactivation due to the POA doing things in its own order?
stefan:	NickElm: yes, that's one of the problem...
NickElm:	stefan: All right, what else then?
	NickElm braces himself.
NickElm:	;)
stefan:	NickElm: in fact, not only the order, but the fact that POAs take all objects down at once, not one at a time.
NickElm:	stefan: Oh.
stefan:	NickElm: so the object which is being destructed can't assume anything about the other objects it's being connected to.
NickElm:	stefan: And no way to hook up to some internal call in the POA and take care of things?
NickElm:	stefan: I see...
stefan:	NickElm: that makes recovery quite difficuly (imagine a linked list for example...)
stefan:	nope
NickElm:	stefan: I can see that.
NickElm:	stefan: But the POA has good mechanisms for activation, why nothing for deactivation?
NickElm:	Oh well.
stefan:	NickElm: because that could cause endless loops.
stefan:	NickElm: 'deadlocks'
NickElm:	stefan: Yesssss....
	NickElm thinks about this.
stefan:	NickElm: it's not a normal condition anyway (shutdown due to POA destruction I mean)
stefan:	NickElm: but since we want to be fault tolerant we have to deal with it
NickElm:	stefan: Yes, I see.
NickElm:	stefan: So this is what happens when the client ping() returns COMM_FAILURE, and we want to garbage-collect the objects belonging to the client by destroying the POA?
NickElm:	This is that situation, I mean, right?
NickElm:	Btw, the meeting is in about an hour an ten minutes?
	misaka nods to Nick.
	misaka thinks that at this rate, he's likely to be 10-15 mins late to it too.
	NickElm got his time zones mixed up and is now calibrating thanks to misaka's thoughtful URL.
misaka:	We should remember to make use of that for future meetings. :]
	NickElm nods to misaka.
NickElm:	I was under the impression that GMT was the same time zone as what they have in London. It seems I was mistaken.
	misaka stares at fresh code modifications.
NickElm:	njs: Hello, O Keeper of the Lore!
	stefan bows to the operator :)
misaka:	They want me to put it in, I want to put it in, but is it worth it right before I leave?
njs:	stefan: hah, too late
stefan:	njs: sorry ;)
	NickElm chuckles.
stefan:	hehe
NickElm:	Everyone: let's play "Catch the operator"!
	njs pounces
	NickElm growls
NickElm:	Not fair. I was in another virtual desktop.
njs:	I'm not going to able to be here long, or for the actual meeting; is there anything that people need to ask me in particular?
njs:	regarding the web site or something
njs:	they both actually seem to be updating and stuff, I'm amazed
njs:	I think this is the first time everything has worked right in months
NickElm:	That's good. :)
stefan:	njs: right, we should have scheduled the meeting a lot earlier ;)
stefan:	nooooo !!
stefan:	what a foolish bug !
stefan:	:)
stefan:	score one for most obscure bug
njs:	stefan: ?
NickElm:	stefan: What?
	NickElm perks up.
stefan:	you know the relationship between a CORBA object and a servant ?
NickElm:	Yes.
njs:	stefan: which is what?
stefan:	in the berlin setting it's such that if an object is deactivated, the servant gets destructed.
	NickElm nods.
njs:	stefan: I understand the theory, I just can never remember which word refers to which part
stefan:	however, I invoked '_this()' in the destructor, effectively activating the object again :)
stefan:	njs: 'servant' refers to the entity which serves the COBRA object. The object is abstract, the servant its representation in a particular context.
NickElm:	stefan: Ahhh...
NickElm:	stefan: Granted, that's an obscure bug. :)
stefan:	NickElm: and then omni complains that I delete an object which is still active...
	NickElm chuckles.
NickElm:	stefan: Implicit acitivation is not all that great in that respect, I guess.
stefan:	NickElm: right. Lots of people warn about it.
stefan:	NickElm: however, you can't do anything about it without rewriting the _default_POA() method.
stefan:	NickElm: as long as the _default_POA() method returns the root POA, you are bound to the policies which come with that.
stefan:	NickElm: since you only can change policies for POA which you explicitely create.
NickElm:	stefan: Yes, I can understand that.
	NickElm nods.
njs:	Anyone have any idea why A dense in B, B dense in C => A dense in C?
NickElm:	njs: dense?
	NickElm must have a terminology problem here.
njs:	NickElm: set theory
njs:	NickElm: or metric space theory, whatever that is
stefan:	njs: it sounds intuitive, but I guess you woudn't accept that :)
NickElm:	njs: So then "dense" is transitive? That's the definition of transitivity, at least.
njs:	stefan: I'd accept it, my prof wouldn't :-)
NickElm:	stefan: Not really intuitive, not for all relations. :)
stefan:	NickElm: well, I guess that would simply be a different way to phrase the same statement :)
NickElm:	stefan: Exactly. :)
njs:	NickElm: well, sort of
njs:	NickElm: it's not symmetric, and A is a subset of B is a subset of C, so it's not exactly the same as what one normally thinks of as transitivity
NickElm:	njs: This calls for a Venn diagram, I think.
NickElm:	njs: You know, the one with circles inside circles. :) A graphical proof is proof enough...
njs:	NickElm: perhaps, but representing closure() on a Venn diagram is, erm, non-trivial
NickElm:	Oh.
NickElm:	That's what dense is. :)
njs:	A is dense in B if A subset B && closure(A) = B
stefan:	anyway, back in a little while...
NickElm:	njs: Right. There's a tiny bit of language barrier here, though. :(
	stefan has quit ([x]chat)
ilya:	Every non-empty subset of C has non-empty intersection with B
ilya:	If you can show that this intersection is open in B, than it should have non-empty intersection with A
ilya:	Thus showing that every non-empty open subset of C has intersection with A, i.e. A is dense in C.
ilya:	Maybe, you can replace 'open subset' with 'sphere' here.
njs:	ilya: how can every non-empty subset of C have non-empty intersection with B? That's absurd.
ilya:	non-empty open subset.
njs:	ilya: oh
njs:	ilya: that makes a difference :-P
	misaka heads home.
misaka:	With luck I'll be there by 21h00 GMT ... but more likely I'll be 15 mins late or so.
stefan:	graydon: what do you think of that mail from BeOS ?
graydon:	that's not from BeOS
graydon:	it's from BeOpen
graydon:	very different
	stefan has quit (Ping timeout for stefan[rubidium.BIOPHYS.UMontreal.CA])
stefan:	sorry, back again
stefan:	graydon: can you repeat ?
njs:	my feeling is that 1) if they want to link to us, fine, but there's no real reason to "trade" links; that's not the point of our site, and 2) no banner ads, berlin has had too much unfounded hype
graydon:	BeOpen != BeOS. BeOpen is a linux development group, basically. they made some xemacs modules, like hyperbole and infodock, a long time ago, and now they're re-targetting themselves as a python development house with a python portal network to back it up.
njs:	though honest banner ads might be amusing... "Berlin: the distant future in computing." "Berlin: cursor control is for weenies."
stefan:	graydon: I see.
NickElm:	njs: I'm sure Rob, for one, would be able to do some banners.
stefan:	NickElm: ah, did you talk to him ?
njs:	NickElm: yeah, I'm just not sure that we want to do advertising stuff right now
njs:	in any case, I have to run
njs:	/msg me anything you want me to answer later
	njs is away: class
NickElm:	stefan: I think that he can whip something up quite easily.
NickElm:	stefan: He can't make it today, he has a bad cold and needs his sleep. :(
NickElm:	njs: See ya!
stefan:	NickElm: oh well, say hi from me anyway
NickElm:	stefan: Then I will. :)
stefan:	graydon: how different is docbook XML from docbook SGML ?
stefan:	graydon: it appears docbook has evolved quite a bit recently, so I'm wondering whether we still need to carry our own environment around.
stefan:	graydon: and at the same time, whether we can just use the XML version of it for our own stuff
graydon:	I'd like to use the XML version. it's not too different.
stefan:	ok, fine. do we still need our own environment ?
stefan:	it appears with the current docbook (4.01 ?) even 'classsynopsis' etc. are supported, i.e. we could even have a docbook version of the reference manual
graydon:	the "our own environment" thing is just to make it easier to build. otherwise we need toa dapt to the person who's trying to build the docs. there's no "autoconf for XML" yet :)
stefan:	graydon: right. Let's wait, Havard is supposed to come today :)
	NickElm is here and ready.
NickElm:	:)
stefan:	may be we could start with the more technical points
ilya:	Program received signal SIGSEGV, Segmentation fault.
ilya:	0x402535f6 in Warsaw::_impl_Graphic::_impl_Graphic () from /home/ilya/berlin/Berlin/lib/libBerlin.so
stefan:	oh well...:)
stefan:	I think we need to improve the home page or just the way we use it.
NickElm:	ilya: That's a technical point, granted. :)
stefan:	Right now there is no working/up to date task list for example
stefan:	what should we do about that ?
NickElm:	Hmm.
stefan:	btw., anybody logging ?
NickElm:	It's definitely true that all project needs some kind of task management, especially a project like Berlin.
danpost:	stefan: I'm logging :) I always log... Even if I'm not one of the core developers yet.
hunger:	HI!
NickElm:	hunger: Hi! Just in time. :)
hunger:	Sorry that I am late.
NickElm:	Trust Tobias to make an entrance.
	NickElm snickers.
stefan:	hunger: really, we have almost finished ;)
hunger:	NickElm: Christina told me to tell you hi!
NickElm:	hunger: Well, tell her hi too! Rob would probably say hi as well, but he's in bed with a cold.
	graydon doesn't know how to log in bitchx, and X isn't working for me today
	NickElm is logging, too.
stefan:	NickElm: too ? anyway, fine.
NickElm:	All right, people are waking up and appearing, good. Misaka will be here soon, too.
danpost:	brb
NickElm:	stefan: Well, dan was logging too. :)
	danpost has quit ([x]chat)
hunger:	Just for the logs: I might be logging too. I never know with xchat ;-)
NickElm:	And Chalky seems to have a never-ending log repository. :)
	NickElm prods Chalky.
	hunger is a irc-newbie that does not want to bother just because of this channel.
stefan:	graydon: do you think the sourceforge task manager is good enough for us ?
	graydon can only stay for about 1.5 hours.
NickElm:	hunger: I found it under Settings \| Setup. It puts my logs in ~/.xchat
graydon:	stefan: it probably will do. at least it can be updated online.
NickElm:	So tasks cannot really be assigned to someone by someone else, but you could take on a task voluntarily or something, right?
NickElm:	like now, in other words, only a bit more formal.
stefan:	ok, then let's use it.
stefan:	NickElm: well, there are always unassigned tasks.
NickElm:	stefan: of course.
stefan:	NickElm: once you start working on them it's a good idea to assign them to yourself to let others know that you are working on it...
NickElm:	stefan: Right, exactly.
NickElm:	stefan: That sounds reasonable, so let's use it. Doesn't seem hard.
	NickElm is there right now.
NickElm:	So, should we move on to something else?
stefan:	right
stefan:	graydon: you are the coordinator, go ahead :)
	NickElm waits eagerly.
stefan:	I'd suggest that we start with a little summary of the last year, especially the last six months.
	NickElm nods.
NickElm:	Including the code work as well as side work, like conferences.
graydon:	well, ok
stefan:	we had two exciting and quite successful presentations in Stuttgart (LinuxTag) and Ottawa (Linux Symposium)...
graydon:	we went to linuxtag and OLS, this much everyone probably knows
NickElm:	I guess you've all seen our ugly mugshots from Stuttgart. :)
NickElm:	I saw some mugs from Ottawa, too. :)
	stefan is still eager to see the photos from Niklas/Robert
graydon:	there's a new console abstraction, freetype fonts work, the libart DK is much faster, we run on omni 3, there's a new resource management scheme in place for reclaiming objects...
NickElm:	stefan: But I thought Rob put up a few of them?
NickElm:	stefan: On the Linuxtag report, not many, but we're all featured there...
graydon:	we run on fbcon, we're fully "3d" even though in orthographic mode still for simplicity
hunger:	NickElm: How is Rob's translation of the LinuxTag posters coming along?
NickElm:	hunger: He got halfway, then had to do schoolwork. I'll remind him to continue when he has the time.
graydon:	what else?
stefan:	we talked to Thomas Hiller, which was the last maintainer of Fresco
stefan:	he seemed pretty interested in our evolution...
stefan:	I'
	NickElm nods.
	hunger nods too.
stefan:	v been playing with the idea to contact John Vlissides as he played an important role in InterView's development
NickElm:	stefan: He named us the official successor of Fresco, did he not?
NickElm:	Hiller, that is.
stefan:	NickElm: yes
NickElm:	As Tobias said, Rob is translating the Linuxtag posters from German to English. Could come in handy if someone wants to put up a poster or hold a presentation somewhere.
NickElm:	stefan: Didn't he talk about possible sponsorship, too?
hunger:	I am collecting useful sniplets for presentations. So if you have some drawings, articles, or whatever, please send them to me.
stefan:	graydon: right, we have a couple of important architectural changes.
stefan:	the Console layer is one of them.
stefan:	it was an attempt to get rid of the explicit dependency of GGI
stefan:	and it turns out that this buys us quite a lot, for example the ability to port to even more platforms.
NickElm:	hunger: You'll get the translations when they're done.
NickElm:	Yes, like CAVEs, for one thing.
graydon:	I can't think of much else. the time I put into berlin this summer was mostly spent with libart(DK\|font) and with jprof.
stefan:	NickElm: yeah, tell us a bit about all that...
	hunger likes CAVEs:-)
NickElm:	hunger: :)
NickElm:	Well, sure...
NickElm:	I started implementing a CAVEConsole as soon as Stefan had finished the Console abstraction.
NickElm:	However, I ran into some problems related to the multiprocess nature of cavelib, the lib I use to be able to perform OpenGL calls on the CUBE.
NickElm:	Actually, it's related to shared memory and how to get the different rendering processes to be able to all access the scene graph,
NickElm:	Or, alternatively, how to build a single display list in one thread, and have each of the three or so rendering processes execute this list.
NickElm:	I got in touch with the company behind cavelib, and they told me that they have a multithreaded version of cavelib in the works, and that I would receive a beta version as soon as possible.
NickElm:	Nothing yet, though.
NickElm:	So, in the meantime, I tried my hand at implementing a GLUTConsole using the console abstraction. This would allow us to run berlin on any OpenGL platform with GLUT.
NickElm:	However, me and Stefan ran into trouble again here, mostly concerning glut not being thread-safe nor instance-safe.
stefan:	yeah, that was a pain...
NickElm:	In theory, however, it worked great. :) We even got output and all that, and we could interact with berlin, but ever so often, glut would roll into a little ball on refuse to work.
NickElm:	stefan: Right. :)
graydon:	yeah. I also started work on an SDL console, partly out of curiosity and partly because GGI is difficult to get stable packages of on peoples' systems.. also stefan and I have been discussing what seems like the next logical step, which is to start building a simple pixel-level bridge to let X apps into a berlin server.
stefan:	and it was slow
NickElm:	stefan: That too. But it was a useful proof-of-concept.
stefan:	NickElm: absolutely.
NickElm:	stefan: We identified a few issues with the console, too.
NickElm:	graydon: how did the console abstraction map to SDL, then? Anything blatantly different?
stefan:	graydon: right. I have been playing with a new interface: Canvas. It's a way to export a shm id together with pixel/drawable alignment info to let clients draw themself
graydon:	NickElm: well, I didn't finish. it looked like it would be a pretty direct mapping though.
NickElm:	graydon: That's great.
stefan:	yeah, it seems SDL follows GGI design relatively closely
NickElm:	Anyway, just to summarize, I am *this
NickElm:	Uh.
NickElm:	Anyway, just to summarize, I am this close to getting Berlin-on-CAVE (in plain, ortographic 2D) running.
stefan:	cool !
NickElm:	I just need a multithreaded cavelib, or rework a drawing kit to use shared memory.
	misaka arrives, a bit later than expected.
	hunger has quit (Read error to hunger[rzppp-70.uni-trier.de]: Connection reset by peer)
stefan:	NickElm: it probably depends on when the mt cavelib will be ready
	aaron appears to have been afk at the wrong time
NickElm:	stefan: Yes, I think so, too.
NickElm:	misaka: Welcome back!
NickElm:	stefan: I am not sure whether the effort to modify the GLDrawingKit to use shared memory is worth it.
stefan:	ok, so just to summarize what the Console layer is:
aaron:	I forgot about the meeting; I've been reading HHGTTG instead ;). oh well, logs work out i guess
stefan:	it provides a uniform way to access some standard functionality you would expect from a Console such as input event generation as well as some simple drawing primitives.
NickElm:	aaron: We've just been at it for about 30 minutes.
stefan:	the nice thing is that with the tie approach we use you can access the special implementation, so if there is some new feature only a particular console implementation provides, you can write a special DrawingKit for it.
	aaron backs off, no input here ;).
NickElm:	I am writing a short doc about the console for console writers, dunno when it will be ready.
stefan:	NickElm: very nice. It may become a chapter in the Tutorial I think.
NickElm:	I gather XML is easier than SGML, so if we are to switch over, I'll wait. :)
NickElm:	stefan: that would be good.
graydon:	um.. so the basic idea with bridging to an X app is to make a little slab of shared memory, say with mmap or shm or something, and a pipe pair, and then fork the app you want to bridge (local to the server) as a subprocess holding these resources. it can then read events from the pipe with select(), paint into the shared memory as a "visual", and signal the server (holding the other end of the pipe) when it wants to redraw.
graydon:	which is (embarassingly) what the "berlin classic" server was supposed to do anyway :)
NickElm:	graydon: Going back to our roots. :)
graydon:	indeed
aaron:	NickElm: docbook works with XML. just use docbook... look at the ORA book online, there's almost no difference
NickElm:	aaron: Okay, I see.
	NickElm is having a slight problem setting up the SGML utilities on his machine--not that he's tried very hard.
stefan:	graydon: yeah. But why needs it to be forked by the server ?
graydon:	stefan: well, depends if you want to use a fifo or a pipe
stefan:	graydon: can't I write an Xlib emulation library which connects to the 'Canvas' object I was talking about for drawing ?
graydon:	or a socket, I suppose :)
stefan:	graydon: yeah :)
stefan:	graydon: well, as long as the events are pure data (as in X) they could be delivered over the very same shm segment.
graydon:	stefan: the pipe/socket/fifo also serves as a synchronization mechanism
stefan:	graydon: right
graydon:	stefan: you need something to signal a hand-off. "this canvas is currently not to be touched as it is redrawing".
stefan:	graydon: well, I thought you could embedd a semaphore into the shm...
graydon:	plus something to put the app to sleep when nothing's happening. you don't want it polling shared memory to look for events. you want select()-like sleeping.
stefan:	graydon: yes, semaphores should work just fine for this as well.
stefan:	graydon: anyway, that are details...
graydon:	a semaphore is also ok. I prefer not to use sysV IPC because it's global, and it seems in the few tests I've done to be slower than mmap and pipes.
graydon:	yeah
stefan:	right, but there are posix semaphores as well...
graydon:	non-global?
stefan:	graydon: ?
stefan:	graydon: you mean multi process ?
graydon:	posix semaphores. are they a system-wide resource like sysV semaphores?
stefan:	graydon: yes
graydon:	i.e. can anyone attach to them, or are they private per-process objects?
stefan:	graydon: well, you can create 'named semaphores'. Then they are multi process semaphores...
graydon:	right. per-process objects like fds seem cleaner to me.
stefan:	graydon: ok, well. One or the other, we could probably play with a number of different implementations.
stefan:	the important point being that we need a low level API for emulators to hook in.
graydon:	yeah
NickElm:	This is also the same canvas that would make direct-access for high-performance apps (like movie players) possible?
graydon:	and soon!
stefan:	lots of people ask about this.
stefan:	yes
stefan:	NickElm: yes.
NickElm:	Excellent.
stefan:	NickElm: though the Canvas is just the rendering part, i.e. without the event handling.
NickElm:	Oh, I see.
graydon:	well, not "direct" access to the video card, but much simpler than rendering into PNGs and transferring them thru the ORB
stefan:	NickElm: in fact, not even rendering, just the frame buffer (or other memory)
aaron:	stefan: I missed a big chunk of this conversation, has the canvas been started or is the idea just being tossed around
stefan:	graydon: might even be direct
graydon:	stefan: might be. but I don't know exactly what fbcon allows.
stefan:	aaron: no serious work. But with the Console abstraction this becomes closer to reality.
aaron:	graydon: this was one of JT's problems with doing region management inside the server. if you have a graphics library that can manage regions for you, something like a canvas can be just a blit.
NickElm:	aaron: JT?
graydon:	and either way, the DK doesn't know how to discriminate between composited and "opaque rectangle" modes, so you're going to go thru libart's compositor anyway.
aaron:	jon taylor, when he was adding his ideas
graydon:	at least, not in a way which permits you to write to a masked section of the framebuffer
	NickElm nods.
stefan:	graydon: depends. We may simply consider the Canvas to be an opaque screen parallel rectangular region. Then we can use simple blits.
stefan:	graydon: or we take transforms, alpha channels etc. into account, then we need to go over the renderer
stefan:	I think I'v read on the SDL list that they support blitting with alpha support.
stefan:	Doesn't this imply that we can blend the Canvas into the scene graph ?
aaron:	stefan: wow
stefan:	well, modulo transformations...
graydon:	well, "supporting" blitting with alpha might mean running a compositing loop over each pixel in software. which is what we do.
stefan:	ok, I guess the Canvas has to become pretty high on the task list's priority
stefan:	graydon: yeah, but it may mean that, if there is h/w support, it can forward this task.
NickElm:	That sounds good, anyway.
stefan:	graydon: which only the Console implementation itself can know. We can't
aaron:	and SDL is under LGPL
NickElm:	stefan: Wasn't sdt interested in something like this? Only I haven't seem him in a long while.
stefan:	NickElm: right. He is in Waterloo, Canada, right now, without much internet connection.
NickElm:	Ahh.
stefan:	NickElm: else he would be interested in fbsd/berlin...
NickElm:	stefan: That's right.
stefan:	and a possible port of his WorldForge project
	misaka wonders how he could be at UofW without a decent Internet connection.
	graydon wonders too
hunger:	UofW?
NickElm:	It seems like all the Berlin developers move to Canada. :)
NickElm:	University of Waterloo?
misaka:	hunger - University of Waterloo
stefan:	NickElm: do they ? :)
	NickElm tries to prod hunger awake.
	NickElm feels the call of Canda, but resists it.
misaka:	Next item on the agenda, immigration assistance for those Berlin developers moving to Canada ...
hunger:	Hey NickElm! Why do you prod me away?
	NickElm chuckles.
aaron:	heh
stefan:	misaka: hehehe. I could need such assistence indeed...
NickElm:	hunger: Cause you're not paying attention!
NickElm:	;)
NickElm:	misaka: That means a cutter picking me up at sea and smuggling me ashore?
NickElm:	Perhaps we should try to get this on track again. :)
hunger:	NickElm: I can see you allready sitting in front of a computer in a dark canadian cellar ;-)
	misaka thinks we should get back on track too. :]
NickElm:	Good initiative.
stefan:	the POA is an amazing animal...
misaka:	Did we skip the 3D additions to Berlin item?
	graydon hands the floor over to Mr. POA.
stefan:	graydon: :)
NickElm:	We'll get there later, thenn.
misaka:	Or was that really covered with the cavelib discussion?
NickElm:	misaka: I'll mention something later.
	misaka nods to Nick.
stefan:	can I assume that everybody is familiar with the general idea of an Object Adapter ?
NickElm:	You may.
aaron:	stefan: problem. doesn't berlin still use omnithread all over the place?
misaka:	Um.
misaka:	Not by name, over here.
	hunger nods.
aaron:	that's one thing to be dealt with before POA gives berlin orb portability
NickElm:	aaron: No, in prague, there are only posix threads.
	aaron zips it, then
stefan:	and Object Adapter maps between objects (abstract entities as seen by the client) and servants (the code implementing the object)
misaka:	Ah, right, I recall the concept.
stefan:	with the POA there is an amazing variety of scenarios how to bind the two together.
stefan:	what we do, generally, is this:
stefan:	all servants are ref counted. When the object is activated (short after the servant is created), the POA takes over ownership (by being the only one holding a reference).
stefan:	this means that as soon as the object is being deactivated, the servant will be deleted. (that is, once the POA decides it is save to do so)
stefan:	ok. So now the question is how and when to deactivate the objects, as this needs to be a local operation.
stefan:	There are three possibilities:
stefan:	you create a temporary object, do some work with it, and release it. So you can call deactivate explicitely.
NickElm:	Maybe you should add that we keep track of objects by grouping them with the clients that created them. This, in turn, is done by creating a dedicated POA for each client, right?
stefan:	NickElm: wait a minute...:)
NickElm:	Sorry. :(
stefan:	the second possibility is an object with a single owner.
	NickElm didn't realize that stefan had this planned out so well.
stefan:	Imagine you ask for an iterator.
	NickElm shuts up.
stefan:	which is created by a (possibly remote) graphic.
stefan:	so you need a method to delete it. All interfaces which are used that way contain a 'destroy()' method.
stefan:	I didn't feel like adding a special interface for that, though
stefan:	Third, there are the objects which don't have owners.
stefan:	they are reference counted, so they deactivate themselfs if the reference counter drops to zero.
stefan:	For this there is the
stefan:	'RefCountBase' interface.
stefan:	with methods 'increment' and 'decrement'.
stefan:	with this, it is possible to manage memory correctly, i.e. to know when a particular object isn't used any more and can be deactivated (and the servant be deleted).
stefan:	does everybody follow/agree up to here ?
misaka:	Yes.
aaron:	ja.
misaka:	One question.
NickElm:	Ja.
stefan:	misaka: ?
misaka:	In first example, the object is deactivated because it falls out of scope?
stefan:	misaka: well, that would be a convenience construct.
	danpost is away
hunger:	me too...
aaron:	stefan: is there a real benefit to having an owner for each object?
stefan:	aaron: what else would you propose ?
stefan:	misaka: in C++ you can write helper classes which do some cleanup if they go out of scope. In fact, we provide a couple of them. ('auto_ptr' is a keyword).
aaron:	stefan: nothing, I just didn't quite understand the function of the second scenario
misaka:	stefan - But that would be an example of how that would be used, or perhaps even the intended use, yes?
aaron:	(as... something that had benefits over the other two)
stefan:	misaka: yes, of course.
stefan:	aaron: sure, it's much simpler.
misaka:	Ok, I'm following then. :]
aaron:	stefan: I just take it that the second option is just for people that like complete control
stefan:	aaron: well, no. It's for a set of objects.
stefan:	aaron: and it's not just for some people who prefer it.
stefan:	aaron: I mean, you may look at it like the difference between static and dynamic typing.
stefan:	aaron: the difference often being robustness.
stefan:	anyway, let's stay on topic :)
aaron:	ok
stefan:	ok, all that I described applies as long as everybody plays nice.
NickElm:	:)
stefan:	what if a client is killed ? Or just forgets to call 'decrease' on a ref counted object ?
stefan:	the question is how we can make berlin fault tolerant
stefan:	as you all know, the server pings the clients if he is curious to see whether the clients are all still alive.
stefan:	if such a ping results in an exception, ot
stefan:	s time to clean up the resources which had been allocated in behalf of that client.
stefan:	And since our POAs contain a list of all active objects (Active Object Map), I thought it might be easy to let them care of the cleanup
	NickElm nods.
stefan:	to do this, we simply give a new POA to each Kit a client allocates.
stefan:	since the ServerContext knows the kits which are allocated, it can deactivate the kits, which triggers all the POAs to be destroyed, and with them, all the objects belonging to the client.
stefan:	that works, but it sounds easier than it actually is :)
NickElm:	stefan: So one POA for each kit, not one for each client?
	NickElm updates his mental model.
stefan:	NickElm: right, one per kit.
NickElm:	stefan: I guess that's more intuitive.
stefan:	NickElm: we may have different security issues with different kits, and different policies with different kits, etc.
NickElm:	stefan: Ahh, quite right, quite right.
misaka:	That's one POA per kit for each client?
aaron:	how big is a POA object?
stefan:	misaka: yes
stefan:	aaron: a POA is mostly behavior, until you start filling the AOM.
stefan:	aaron: so it's as big as you make it by activating objects with it.
NickElm:	The knowledgeable people on comp.object.corba (like Michi Henning), told stefan that this was exactly the kind of application the POA was made for.
stefan:	what concerns me more isn't the size of the POA as the time a method dispatch takes since you have to find the matching POA from the IOR...
aaron:	stefan: ok, fine then. simple clients will devote very little room to their POAs then
stefan:	NickElm: right.
stefan:	aaron: yeah
NickElm:	aaron: Besides, the alternative would be to keep a list of the created servants for each client, and that would essentially be redundant information, since the POA already has all of that in its active object map.
aaron:	stefan: I wondered about that as well, but I don't want to be too much of a smart ass ;) figured someone else would broach it
NickElm:	stefan: There's been any benchmarks on that? Is that an issue?
stefan:	NickElm: well, I assume the simplest alternative would be to have a single POA per client.
stefan:	NickElm: no. I asked on comp.object.corba whether scalability is an issue with this approach. They said it is not.
stefan:	anyway, it should be trivial to change from POA-per-kit to POA-per-client (which is the least we need)
NickElm:	stefan: Yes, I'm not saying this is wrong, I'm saying that if we were being ignorant, we would have had a single POA for all of Berlin and keep track of all of this ourselves. Redundant. So we don't.
stefan:	NickElm: right
aaron:	stefan: the display server has an IOR for every object involved in the scene graph right?
stefan:	ok, so now what I have been doing lately:
stefan:	if a POA is being destroyed, none of it's object is available.
stefan:	that means that within the cleanup there are lots of CORBA::OBJECT_NOT_EXIST exceptions being thrown
stefan:	so we need to catch those
stefan:	aaron: yes
stefan:	aaron: well, not exactly. Depends on what you mean by that.
aaron:	stefan: just wondering if you have to hop from POA to POA to find an object that's drawing to the scene graph, ever.
aaron:	nevermind.
aaron:	off-topic.
stefan:	aaron: well, if you have an object reference, it contains the name of the POA as well as it's 'ObjectId', which is unique only in the context of its POA.
stefan:	aaron: so what the ORB does is figure out the POA, then ask it to call into the servant being associated with that ObjectId.
stefan:	aaron: the naming of the POA is up to the creator, i.e. you. You can make short names, as long as they are unique.
NickElm:	stefan: Btw, have you done any benchmarks on berlin and compared performance before and after the POA switch?
stefan:	aaron: I'm currently using the repoId of the Kit as the name, plus a counter (since there are multiple instances of the kits, one per client at least)
aaron:	stefan: is network latency ever an issue? suppose one complicated client died and the server received 200 OBJECT_NOT_EXIST exceptions... would this clog up any important threads?
aaron:	stefan: ok, that answers my question
aaron:	no behavior similar to triple dereferencing.... good thing, that wouldn't be smart on a network protocol
aaron:	triple/quadruple/n-....
stefan:	NickElm: no. It's definitely a bit slower, due to the robustness we get. (one more indirection in local calls).
NickElm:	stefan: Just curious. I'm all for the robustness anyway.
stefan:	graydon: did you contact Duncan to discuss the mutex stuff ?
stefan:	oh well...
	aaron has 10 minutes
aaron:	if you want me to do anything to purcel or orbital, now's the time
	graydon did not talk to duncan. i'm bad.
NickElm:	aaron: take it down?
NickElm:	;)
misaka:	purcel? orbital?
NickElm:	Web servers?
stefan:	graydon: may be we could start a discussion with him on the omni mailing list.
aaron:	NickElm: nah, I don't feel like being banned from sourceforge or debian thank you ;)
aaron:	NickElm: yes
stefan:	graydon: he is very responsive. He told me the is_identical trick btw. :)
NickElm:	aaron: Awww, don't be such a coward. :)
	NickElm is sidetracking again. Must be that his bedtime is approaching.
Peaker:	Hey, what's the advantages of Berlin over a system like NeXT's windowing system, that used PS?
hunger:	NickElm: You go to bed this early? Warmduscher:-)
aaron:	Peaker: very little right now but conceptually, a lot.
stefan:	ok, so while I'd really like to get the next release out of the door, I'm also a bit reluctant while there are still a couple of obvious bugs. (even though the solution is less obvious :(
	NickElm ignores hunger.
aaron:	Peaker: kind of a meeting in session right now...
Peaker:	aaron: I'm curious..
Peaker:	oh
graydon:	Peaker: it's free software, not written in PS and ObjC, and it's available for download right now :)
misaka:	stefan - I'm with you. Stability is important, especially as perceived by others.
stefan:	I played with the python applets and the run nicely. You can start them, kill them, the server still serves :)
NickElm:	misaka, stefan: Yes, definitely. We wamt to be as stable as possible. It's not as if people are pressuring us to release, it's up tou s.
aaron:	stefan: is berlin at a point where keeping bugs in a bts is more feasible now? I mean, even just as a source of information for onlookers
misaka:	I'd guess that we can deal with having a reputation for being slow with releases, and that's certainly better than buggy releases. :]
Peaker:	graydon: I'm referring to technical advantages though :) ObjC doesn't make it worse in principle, and what's wrong with PS?
stefan:	so I'm actually trying to rewrite the C++ demo in python and then debug it line by line. (feature by feature that is...)
graydon:	Peaker: it's imaging model is good (as is ours) but DPS locks you into a particular language. we are corba-based.
stefan:	Peaker: did you look at any of our docs ?
Peaker:	stefan: Long ago
Peaker:	stefan: Are there references to NeXT's system?
stefan:	aaron: good point.. I'd like to make much more use of the online project management tools, if only to get more people involved.
aaron:	Peaker: CORBA at a much higher level than X's network protocol, so bandwidth is a much smaller issue too. As well as very elegant layout mechanisms inherited from fresco.
stefan:	aaron: however, some of the reported bugs are a bit rediculous: 'server crashes' etc. You get the idea...
misaka:	stefan,aaron - I believe that's a topic on the agenda. :]
Peaker:	aaron: But the bandwidth in NeXT's system was low as well, the PS could contain functions to implement the layout, as I understand
aaron:	stefan: I mean, perhaps a developer maintained database. you guys know more about the bugs than anyone else, and it would be nice to see your description of the bugs you're working on
stefan:	Peaker: not much. But still, if you know NeXT, and you read our docs, you may make up your mind yourself.
stefan:	aaron: fair enough.
aaron:	Peaker: have you ever read the GOF book?
Peaker:	stefan: I'm sorry to say I'm just interested as a result of hearing people's oppinions, but I only know the basics of each
stefan:	anyway, I think that I'm really close now so the release should follow Real Soon Now...
NickElm:	Btw, speaking of the upcoming release, I committed my initial work on the 3D stuff, now called PrimitiveKit. :)
aaron:	most of vlissides' examples are straight out of interviews (Interviews -> Fresco -> Berlin, that's the genaeology)
stefan:	NickElm: right, which brings us to the next topic, and to the future directions :)
NickElm:	No implementation, just a few interfaces. I didn't have time to do it right before I got involved in the Console...
NickElm:	stefan: Right. :)
NickElm:	What are the future directions, then?
NickElm:	I, for one, will try to juggle my time with Berlin and work on the PrimitiveKit and the CAVEConsole (whenever I get my hands on a MT cavelib).
NickElm:	I really would like to see Berlin in the 3D-CUBE.
hunger:	Peaker: As I see it (not knowing PS/DPS very well) berlin is much more abstract, allowing for non 2D interfaces that NeXT never thought about.
aaron:	NickElm: does cavelib normally work on top of 3d accelerated hardware?
Peaker:	hunger: It seems to me that there's a problem of lack of API competition, in the widget set/etc, since there will only be one :)
NickElm:	aaron: Yes...
hunger:	Peaker: Only one interface:-)
NickElm:	Peaker: but the widgetkit is pluggable, so that is not quite true...
aaron:	NickElm: will you have to write an entire cavelib 2d drawingkit to make your first primitivekit that can interoperate? or will they be two completely separate and independent pieces of code?
hunger:	Peaker: One interface does not mean one implementation! You can have a motif-button, a qt-button or a button-object in a 3D environment.
Peaker:	hunger: Yes, but the competition on the interface side also helps :)
aaron:	Peaker: the trouble is just getting the interface right. and if you still want to do gtk (shudder) after you figure out berlin's interface, that will eventually be possible
NickElm:	aaron: No, fortunately, the cavelib stuff only touches the console, not higher in the abstraction layers. This means I only need the CAVEConsole. I have already adapted the GLDrawingKit with the slight changes needed to make it work with the CAVEConsole.
aaron:	NickElm: so CAVE can cooperate with openGL
NickElm:	aaron: And the PrimitiveKit is, of course, totally independent from the actual drawingkit implementation. It only needs the Dk to support a DK3D (which I also defined as an interface).
NickElm:	aaron: Yes, the purpose of cavelib is to be able to use IrisGL or OpenGL on top of the CUBE hardware.
aaron:	Peaker: personally, I think fresco did it right. better than any other GUI interface I've taken the time to understand...
Peaker:	aaron: How do signal/slots work there?
	graydon needs to head out. see y'all..
aaron:	Peaker: you mean callbacks? Qt's signal/slot mechanism is just a macro trickery for callbacks
misaka:	later graydon
NickElm:	graydon: See you!
hunger:	Bye graydon
aaron:	Peaker: and the answer is, berlin uses an abstracted form of callbacks that work with CORBA. no difference here ;)
	graydon has quit ([BX] Dr. Kavorkian is DYING to use BitchX. Aren't you?)
Peaker:	aaron: Gtk-- also implemented signal/slots, with templtaes
Peaker:	aaron: Are they static-type safe?
aaron:	Peaker: explain yourself, I'm a bit behind on jargon.
aaron:	(that wasn't a hostile remark, just, jargon is jargon, and static-type safe isn't a term I know ;)
NickElm:	Well, moving on...
Peaker:	aaron: Well, if a signal invokes a callback that receives an int, you shouldn't be able to connect it to a callback that recieves nothing
aaron:	stefan: can commands receive something other than an Any?
Peaker:	aaron: the point of signals/slots is to have type safety in the callback mechanism, which is a very good point
Peaker:	to make sure what is sent, is what is received, and to not have to have the inconvinience of always receiving a void*
Peaker:	(or 'Any')
stefan:	aaron: that's a strange idea: 'something else than any'
stefan:	aaron: :)
aaron:	Peaker: yes, they are, but in an odd CORBA-ish way. If I understand correctly, it's the equivalent of being passed a void *, and the slot method will try to narrow that (ie, dynamicCast, if you will). if it doesn't work I think your slot will throw an exception
Peaker:	aaron: static type safety merely means that the test is done statically, at compiletime
stefan:	ok, to get back on track. I have some ideas of what we need in the near and not so near future
	NickElm is all ears.
aaron:	but let stefan elaborate on that.
Peaker:	aaron: Ok, but to me as a programmer, it seems that I receive the correct parameter list?
stefan:	the near task at hand is robustness, which I hope to settle with the next release
aaron:	Peaker: as the programmer whose code is being called back
	hunger listens to stefan.
aaron:	I'm not really sure. ask stefan, for now I have to go. and sorry for interrupting, everyone ;)
hunger:	Bye aaron!
NickElm:	stefan: Excellent. Then that will be squared away, we can hope.
misaka:	later aaron
NickElm:	aaron: See you!
stefan:	then, we need to make berlin attractive as an actual coding platform for application writers. This implies a complete WidgetKit, as well as a working Canvas implementation such that people can write client side emulators for gtk, etc.
Peaker:	Bye aaron
	aaron has quit ([x]chat)
Peaker:	stefan: Why is a Canvas necessary, why not wrap the Berlin Wigdet kit interface with GTK's interface?
Peaker:	stefan: (supporting non-gdk programs)
NickElm:	stefan: Is the widget kit interface stable, btw?
stefan:	NickElm: well, it is, ahm, minimal right now. And even that is probably an euphemism.
NickElm:	stefan: That's what I thought. :)
stefan:	NickElm: we need to find all the common widgets and implement them.
NickElm:	stefan: Yes. Easier said than done, though. :)
stefan:	NickElm: which should be relatively simple. The reason I didn't work on the WidgetKit more was that I felt that the underlaying structure wasn't robust enough.
stefan:	NickElm: now it almost is, so this becomes an issue once again.
NickElm:	stefan: I'm talking about finding all the common widgets, not implementing them...
stefan:	NickElm: in fact, it's not just a flag WidgetKit implemenation. Common sub tasks can be implemented inside the ToolKit and the CommandKit for example.
stefan:	NickElm: out of which the WidgetKit can generate widgets...
NickElm:	stefan: The problem I see is that once we commit to an interface, it is hard to change it.
stefan:	NickElm: right
NickElm:	stefan: Yes...
stefan:	NickElm: right. So the interfaces need to be minimal, much in the spirit of what we have.
NickElm:	stefan: But still be able to be extensible? How do you do that?
stefan:	NickElm: in fact, I'm not sure that we really need more interfaces.
NickElm:	stefan: No, quite right.
stefan:	NickElm: may be one more for non flat choices like menus, i.e. to traverse them.
NickElm:	stefan: Since we can just return scene graph subtrees, we can hide the actual implementation of the widget from the client.
NickElm:	Or Graphics, that is.
stefan:	NickElm: precisely.
hunger:	Peaker: The canvas is supposed to get us X-compatibility.
NickElm:	Peaker: pixel-level X compatibility, even, I think?
Peaker:	hunger: Oh, but toolkits are better off wrapped than emulated, don't you think?
stefan:	NickElm: yes, as the Canvas is about pixel based drawing, not vector based.
hunger:	Peaker: A gtk-wrapper would be great to have (since we can add more berlin-stuff to it), but X-compatibility is more important right now.
misaka:	And less complex ...
stefan:	Peaker: you are welcomed to write a widget bridge, really !
misaka:	Or so I've been reading.
NickElm:	stefan: But concerning the widgetkit interface, how can we fix it and still support extensibility without reverting to some dynamic scheme?
NickElm:	"fix it" meaning "freeze it".
stefan:	NickElm: hmm, what do you mean by 'fix' ?
Peaker:	stefan: heh, point me to documents of what to bridge to, and I might find time to start it up :)
hunger:	Peaker: You are right, but it is also more work to do good wrappers for all kinds of libs (qt, gtk, wxwindows, ...) then to do a single X-wrapper.
stefan:	NickElm: the idea is to have a factory method per widget. What it returns is still a Controller. Once we know how many different widgets we want to support, we can 'fix' the WidgetKit interface.
NickElm:	stefan: Okay. Right.
Peaker:	hunger: The vast majority of applications are Qt/Gtk
NickElm:	stefan: But what if we want to extend that later? That would be impossible?
stefan:	NickElm: and even then, if ever we need to change the interface, all that is required is a recompilation of all parties using it. It's not like with closed source packages...
NickElm:	All right.
Peaker:	hunger: I think I know enough of both Qt and Gtk to start wrapper work
hunger:	Peaker: Great!
NickElm:	I'm just a little bothered about this, is all. :) I keep running into the same problem in other projects, notably 3Dwm. :)
Peaker:	hunger: I don't know ANYTHING about the Berlin interface though
hunger:	Peaker: But we don't have anything to wrap it onto:-)
stefan:	Peaker: when did you last look into Warsaw ?
Peaker:	stefan: ages ago :)
stefan:	Peaker: then what are you complaining ?
Peaker:	stefan: am I complaining?
stefan:	Peaker: yes, it sounds so. You keep asking 'why' and 'how' and I keep pointing out to you that you should have a look into the docs we provide. At least for a start...
NickElm:	;)
Peaker:	stefan: Hmm.. Those are not criticizing questions, those are curiosity questions, sorry to sound that way :)
misaka:	Maybe Peaker doesn't realize we're on an agenda now. :]
stefan:	Peaker: then we might gladly accept your help to write bridges :)
NickElm:	Peaker: Actually, it's great to get someone who can help us with this part.
stefan:	Peaker: oh, I pretty much like substantial discussions, that's fine.
Peaker:	NickElm: Cool.. But I don't know what to make of what I read now - is there or is there not what to bridge to right now?
stefan:	yes, absolutely.
Peaker:	Where can I read about it?
stefan:	Peaker: have a look at the general discussion about the scene graph and the way we use it.
stefan:	Peaker: then have a look at the WidgetKit interface to see how we instantiate a button (for example).
NickElm:	Peaker: There isn't. We're planning to add an pixel-level bridge as soon as possible. We only have Warsaw at current.
stefan:	Peaker: then you might think about how you could wrap such a call into a gtk button creation function.
Peaker:	stefan: Any more specific URL's?
stefan:	Peaker: such that gtk apps create berlin buttons when they think they create gtk buttons...
stefan:	Peaker: what about www.berlin-consortium.org ?
Peaker:	heh, that's why I said specific :)
Peaker:	ok I'll look for it
NickElm:	Peaker: Try http://www2.berlin-consortium.org/docs/html/berlin-tut.html
misaka:	Peaker - There's a tutorial there that should prove usefull.
misaka:	The one NickElm just pasted in.
stefan:	the fresco tutorial is even better...
Peaker:	ok, thanks
NickElm:	Yes, Fresco is at http://www2.berlin-consortium.org/fresco/tutorial/
	stefan couldn't imagine that anybody finding us here didn't know about our home page...
NickElm:	Well, finding the actual docs could be difficult. I'm not that found of the site layout. :)
Peaker:	stefan: I knew about the home page
stefan:	NickElm: point taken :)
Peaker:	stefan: I was asking for a more 'specific' URL but never mind :)
stefan:	Peaker: do the URLs the others gave you help ? (the berlin and fresco tutorials)
Peaker:	yeap
Peaker:	saves some browsing :)
stefan:	Peaker: then there are all the research papers, the wiki page, etc.
stefan:	Peaker: we now even have a search engine
hunger:	We have a search engine? I have to look at our homepage again.
	hunger blushes to a crimson red.
stefan:	for a more long term development I'm thinking about the model domain and how to add storage capabilities.
	NickElm is just as ignorant, and joins in.
	misaka plugs in his Newton to cache the Fresco tutorial.
NickElm:	stefan: Mmm, yes.
stefan:	does anybody know DOM here ?
hunger:	nope.
	misaka only knows it roughly.
stefan:	the interesting thing about a storage system is that it provides the means for a range of different things.
NickElm:	like real session management, for one thing.
stefan:	from persistent objects (sessions for example) over data exchange (clipboard, drag'n'drop, ...) up to data recovery.
stefan:	NickElm: precisely
misaka:	The storage system involves the serializing of objects in the scene graph? In broad terms?
NickElm:	What was the scheme we were planning? Storing it as XML using our own DTD?
stefan:	misaka: well, yes and no. what we want to store are the models (in the MVC paradigm), not the graphics.
stefan:	NickElm: that shouldn't matter at this point. The storage interfaces should allow that as well as anything else.
misaka:	stefan - Ah. Right.
NickElm:	stefan: I see.
stefan:	take for a moment OpenDoc:
stefan:	there you have a 'Document' which is composed out of 'Parts', which consists of 'models', i.e. text buffers, rasters, whatever...
stefan:	it's a DAG, which is somehow isomorphic to the scene graph. However, the scene graph 'views' the model graph.
stefan:	you can have multiple views associated with a single model. That
stefan:	's what we get with MVC
stefan:	anyway. The model graph is a polymorphic graph. Storing it means to create a 'pure data' representation of it.
stefan:	I thought about creating a shadow graph of 'ObjectState' objects, which are mostly buffers for all the objects.
NickElm:	Hmm.
stefan:	this you could simply dump to a data base with XML or any other formatting.
falvim:	hmmm
NickElm:	Persistent memento?
NickElm:	;)
stefan:	and you create a new model graph with it with a factory which knows how to generate real objects out of the 'ObjectState' instances (and their stored repoIDs)
stefan:	NickElm: yes.
NickElm:	Neat...
stefan:	NickElm: here you go:
stefan:	if an application wants to provide backups (as emacs for example), it has to store the model graph regularly.
stefan:	therefor it would be wise if all the models keep a modification time (much like the 'cacheable' concept we have been discussing) such that it can decide whether the associated ObjectStore is still up to date or not.
NickElm:	stefan: Yes, I see.
stefan:	Also, the ObjectState could contain a version, such that you can safe multiple drafts of a single document.
stefan:	there are lots of possible scenarios.
stefan:	(I'v been reading the OpenDoc specs over the summer...:)
	NickElm can tell.
NickElm:	;)
NickElm:	(Actually, I can't really, but I could figure it out... ;) )
	misaka is content with believing it. :]
	NickElm is above people like misaka.
NickElm:	;)
stefan:	and finally, if you want to put something into the Clipboard, you simply create an ObjectState from your object and hand it over to the Clipboard such that the peer can try to reinstantiate it or do whatever it wants with the data.
	hunger is a firm believer:-)
misaka:	Hrm. Interesting.
stefan:	anyway, just to point out that I think a good storage system will serve us well.
stefan:	falvim: do you have any thoughts on this ?
NickElm:	stefan: But when you speak about the "model", you mean the model as in the scene graph?
stefan:	NickElm: the scene graph doesn't contain the models, it contains views which observe models.
NickElm:	stefan: Right...
falvim:	I could, if I knew more about the data in question.
stefan:	NickElm: so there is a coupling between the scene graph and the model graph, but that's all
NickElm:	stefan: But what is the model graph, then? I'm a little confused.
stefan:	NickElm: imagine a page you download with netscape.
stefan:	NickElm: what you see is a rendered scene graph.
NickElm:	Yes.
falvim:	My problem is that the details and the overall functionality escapes me a bit,
stefan:	NickElm: but internally, there must be something else. At least abstractly.
stefan:	NickElm: you can select text from it and copy/paste it to a different window.
NickElm:	falvim: I'm sorry, I've never seen you here before, you are an expert at these things? ;)
falvim:	but if I had some hints I could start an abstract model or something to start from
stefan:	NickElm: I'm just trying to understand how this needs to be designed.
NickElm:	That was not an aggressive question, btw. :)
	Peaker has quit (Gotta make history)
misaka:	stefan - Makes sense. Does the model graph currently exist?
NickElm:	stefan: Yes, I see. But what is the model graph in terms of berlin?
	NickElm nods at misaka.
hunger:	stefan: The model-graph is basically a list of things (pictures, text, programs, ...) with placement information?
stefan:	misaka: no, we only have individual models (see what the CommandKit creates for example)
stefan:	misaka: but once we want to write real applications, especially structured documents, we need to care about an actual graph of models
hunger:	stefan: leaving out the messy details that is...
falvim:	NickElm: I´doing some anthropological research here. But I would like to contribute. I´ve worked as
stefan:	hunger: well, not placement information, no. That's something only a particular view needs to care about.
NickElm:	stefan: So the model is stored on the server? I thought it was part of the client, for the most part at least. Or is this a question of terminology?
stefan:	hunger: model graphs need to know about containment only.
NickElm:	falvim: Ahh, I see. I was just curious.
falvim:	a data-modelling consultant for more than a decade now.
stefan:	for example: a document consists of one part, which consists of text.
hunger:	stefan: Placement information in the sence of "object x is part of object y".
hunger:	stefan: That's what I meant.
NickElm:	falvim: Then I can see that you have proficiency in the area. :)
stefan:	another example: a document consisting of two parts, one being text, the other a raster. Etc...
stefan:	NickElm: no, the model is not kept in the server. But the server needs to care about session management and data exchange, at least it needs to coordinate them.
NickElm:	stefan: Okay. I can understand that.
	NickElm yawns hugely.
falvim:	NickElm: I really dunno, but I hope my former clients think so :)
misaka:	We've been at this for 2.5 hours ...
stefan:	NickElm: and if you want to embedd one application into another (i.e. associating different part editors with different parts of a document), the server plays an important role as well...
NickElm:	stefan: I see your point.
stefan:	ok, fine :)
	NickElm surrenders.
NickElm:	:)
misaka:	stefan - So the client/application will need to provide us with some kind of interface to the model they have?
NickElm:	falvim: ;)
stefan:	hmm, what else ? Havard isn't here tonight, that's a pitty
stefan:	misaka: well, as always in corba, each object needs to support a couple of interfaces.
NickElm:	Yes, what else.
misaka:	Or would Berlin be more involved with the creation of the model than that? Maybe providing an interface to the client/application?
stefan:	misaka: for example, all models should be 'storeable'
NickElm:	How about the use of the name "Fresco" in conjunction with "Berlin"?
NickElm:	Perhaps as part of hte logo.
stefan:	misaka: so whoevere happens to own a 'store' can ask these models to externalize themselfs into it.
NickElm:	Us now being the official descendants of Fresco.
misaka:	stefan - Ok, that makes it a little more clear.
stefan:	misaka: no, I'd really prefer the clients to care about the models, that's not the domain of the server.
	hunger agrees with misaka.
misaka:	Right, I agree.
misaka:	So the client would have to provide for those interfaces.
stefan:	misaka: but still, the server needs to have access to the interfaces, i.e. it needs to coordinate data exchange etc.
misaka:	And we would define what the interface is that they must provide for.
stefan:	misaka: the implementations, yes.
misaka:	we == the Berlin server.
	misaka nods to stefan.
stefan:	NickElm: "Berlin - the Fresco Company"
	stefan grins
NickElm:	stefan: :)
NickElm:	stefan: "Berlin -- We Make Frescoes." And then a hammer and a chisel and some paint as part of the logo.
hunger:	I would prefer Berlin - the Fresco Factories.
misaka:	''The Berlin - Fresco Conglomorate'' ?
stefan:	NickElm: a hammer ??
misaka:	Hammer and a chisel??
stefan:	NickElm: you paint frescos with a hammer ?
falvim:	Stefan: It has a peculiar meaing in portuguese...
stefan:	falvim: what ?
NickElm:	stefan: Hehe, maybe not.
	misaka gets that confused with a sycle (sp?).
NickElm:	sickle?
misaka:	Ah, that looks right, thank you.
NickElm:	But say you want to get your block of stone and carry it around?
misaka:	It's been a while since I had to worry about that particular symbol. :]
stefan:	well, hammer and sickle is something entirely different, right misaka ? ;)
NickElm:	misaka: lol
stefan:	hehe
misaka:	Indeed ... indeed.
	stefan knows it all too well...
NickElm:	No, let's have a scythe. Healthy tool, the scythe.
stefan:	yes, and a lot of water...
NickElm:	I'm getting tired.
stefan:	anyway. misaka has been working on a terminal emulator, i.e. a parser to report control sequences...
NickElm:	Stupid ideas are popping up everywhere...
stefan:	NickElm: right, that's normally a sign...
	misaka nods to stefan.
hunger:	Is somebody spellchecking this?
misaka:	Unfortunately there's not much progress to report. Except that I'm certainly gaining a better understanding for how to do it.
stefan:	we need to make the terminal more functional, to support at least the more basic editors like vi.
	misaka was planning on aiming directly for xemacs, but ... :]
NickElm:	Whoever writes the first bit of Berlin code inside Berlin gets an award!
misaka:	My approach at this point is to write a basic terminal emulator, and then work on integrating that with Berlin properly.
hunger:	misaka: Do you need locale support?
misaka:	I think I'm at a point where I can get the basic terminal code decoder working, but that'll certainly have to wait untill after my trip.
misaka:	hunger - Er, I'm not certain at this point.
hunger:	I'm just curious, because I am thinking about writing a locale manager.
	hunger grins.
misaka:	I don't yet see how locale support would be worked in. This part, at least, is strictly looking for specific terminal codes and invoking callbacks.
NickElm:	hunger is the l10n and i18n guy around here. :)
misaka:	I may need that at some point to understand the stream coming in, I suppose.
	NickElm has finally understood what those acronyms mean, and is suitably amused.
misaka:	Nick - ?
stefan:	NickElm: hehe
hunger:	Everything I need to get Prague::Unicode of the ground is locale dependent since those guys came up with their new version:-(
NickElm:	l10n and i18n?