| | #fresco 33 The fresco (formerly Berlin) windowing system. || IRC meeting: 2004-01-19 at 23:00UTC - njs at least would appreciate it if people could read his messages to the list beforehand || http://www.jacksonh.net/jackson/images/godkills_bugs.jpg |
| stefans: | starseeker: that was a pretty abstract one. I was more thinking of a concrete list: 'location transparency', 'object model', 'imaging model', etc. |
| hunger: | njs: Good. |
| mourad: | (Im still catching up with ReFresco01 - very interesting) |
| stefans: | nicholas: do you have any suggestions ? Want to coordinate the meeting ? |
| stefans: | nicholas: (you called for the meeting first :-) |
| nicholas: | stefans: well, I suppose I want to know whether a) are we still supposed to be a replacement for X? |
| hunger: | stefan: Shall we use the list on http://www2.fresco.org/introduction.html as a guideline? |
| | rapha_ (~Raphael@p5085C3AC.dip0.t-ipconnect.de) has joined channel #Fresco |
| njs: | Well, you know what the biggest topic I want to talk about is :-) |
| nicholas: | I want some very broad direction of what are and what aren't our goals! |
| stefans: | nicholas: I believe yes, though we obviously ought to define what that actually means |
| nicholas: | X offers a lot. Surely we aren't about display drivers. |
| njs: | nicholas: not if we can help it ;-) |
| stefans: | nicholas: oh. Well, we want to offer something equivalent in terms of usability. How we achieve this, i.e. whether we delegate to other tools is a different matter (even though very important to discuss) |
| starseeker: | Do we take up the Corba thing? |
| nicholas: | I wasn't specific enough. Are we a project working to produce an X replacement, or are we working to provide a research vehicle for future 3D GUI work? |
| ShelterIt: | Yeah, let us jump into the deep end. CORBA is the one of the most importance right now. |
| stefans: | nicholas: ah, that's already much more difficult :-) |
| njs: | nicholas: I don't care about being a research vehicle for future 3d GUI work. In particular since I'm not all that interested in 3d GUIs :-) |
| starseeker: | That's my personal feeling |
| stefans: | hmm, to CORBA or not to CORBA. Is that really the central question ? Shouldn't we rather talk about location transparency, whether we want it, and if so, where ? |
| hunger: | nicholas: I'm in favour of a exxperimental (3D) GUI system. |
| starseeker: | After all, the monitor is 2D |
| BenB: | nicholas: I haven't seen a 3D gui in fresco (not what I think of it, anyways) :) |
| hunger: | nicholas: What good is it to do something similar to what is already there? |
| BenB: | starseeker: most of them are, but there are 3d ones .) |
| rohara: | perhaps we should start with hunger's suggestion as it will answer these questions. |
| hunger: | nicholas: And an experiment can always turn into an replacement. |
| cow: | hunger, that would be interresting, agree |
| nicholas: | All I've seen of 3D GUIs, which amounts to computer game interfaces really, is using the 3D hardware to render a pretty 2D interface. |
| mourad: | hunger: yes but the question becomes: do you want your implementation to be used by real users, in the end? |
| starseeker: | BenB : Since a human being can only directly see 2D at any one time (3D is deduced) how does 3D help? Multiple simultaneous viewers? |
| njs: | I think our goal is to design a clean, powerful, and practical system for running GUIs. One test of whether we've achieved that is if 1) people who want to build fancy new stuff find it easier because they base it off us, 2) we can accomodate fancy new stuff once it gets figured out |
| | hunger agrees with njs. |
| | stefans too |
| nicholas: | Accomodate at what expense? Full backwards compatibility? |
| njs: | That's just a test, though; I'm not really planning on doing it myself, at least not yet... |
| mourad: | Personally, I'd like to see a GUI that could scale well from small limited displays ala picogui to fullon 3D. ie abstraction, and the semantic thing |
| stefans: | mourad: yeah, I believe that should remain one central goal. |
| starseeker: | My thought on that: Fresco is being developed on very powerful hardware, unlike X - we can build in much more abstraction |
| | njs is not as worried about tiny tiny displays as picogui. But then, I would say that, seeing as I'm proposing a protocol that requires holding lots of long random numbers in memory all the time :-) |
| stefans: | mourad: make fresco scale well and adapt to very different hardware (and people's requirements) |
| nicholas: | X scales to any framebuffer. Yes? |
| ShelterIt: | So the question is whether we will innovate something cool or streamline something already done, or perhaps a merge of the two? |
| hunger: | How about some brainstorming? What is the most important aspect that fresco should archive (in one word)? |
| starseeker: | stefans: Question - adapting to different hardware a matter of drivers primarily or of design? |
| oxygene: | nicholas: its primitive list is small enough to do in slow software, yes |
| BenB: | njs: CORBA is not really fitting for cell phones eithe r:) |
| njs: | nicholas: well, I dunno how well it'd work at 16000x12000 resolution... |
| mourad: | nicholas: yes, but is it useful with tiny (albeit high res) displays? |
| BenB: | (not yet) |
| oxygene: | hunger: vector graphics + compositing |
| starseeker: | hunger: flexibility? |
| stefans: | nicholas: oh, by 'scaling' I mean not only that. It should also adapt in terms of what kind of GUI is used. The whole 'tasket' idea, remember ? |
| oxygene: | hunger: scalability of hardware (display + cpu) |
| | hunger votes for consistence. |
| mourad: | semantic abstraction |
| nicholas: | stefans: that's neat! I never thought we would make that a central goal of Fresco! |
| starseeker: | hunger: Across toolkits, or platforms? |
| oxygene: | starseeker: both? :) |
| stefans: | starseeker: design. Because different hardware has different capabilities. |
| BenB: | hunger: usability |
| nicholas: | stefans: so that smaller systems follow GUI designs intended for smaller systems. Like how PalmOS has only one program window at a time. |
| mourad: | nicholas: right! |
| hunger: | starseeker: A consisitent UI. |
| nicholas: | We we are indeed a desktop system, capable of displaying onto some sort of backend. |
| njs: | Overall I think that being scalable to small (in cpu and memory) systems is nice, and I think if we focus on making our architecture concise and simple, we'll probably do fairly well here. But I think it's a lower priority than making a good clean system for everyone else. |
| starseeker: | stefans: OK. How does one approach that then - break down the capibility of various hardware components and fit them into an abstraction? |
| cow: | starseeker, fresco should imo not care about drivers |
| nicholas: | And we should have different "policies" for different target systems. |
| starseeker: | _cow: I agree |
| stefans: | nicholas: yeah, that was always one of the more interesting aspects |
| BenB: | hunger: though mourad's "semantic abstraction" is also near to my ideas of fresco |
| oxygene: | BenB: ooui? |
| starseeker: | I like "semantic abstraction" |
| njs: | It's also one of the more "more fundamental research needed" aspects; I'd like to have a better idea of our foundations before trying to figure out to what extent we can make clients magically adapt to their environment... |
| hunger: | Shall we go down the list of those important things (plus those from the website) now one after another? |
| stefans: | mourad: with 'semantic abstraction' do you mean what we discussed as 'taskets', i.e. abstractions of widgets into hardware specific user interaction ? |
| oxygene: | hunger: sounds good, to get some structure |
| stefans: | njs: er, did you say 'clients' ? |
| njs: | I don't like "semantic abstraction", because "semantic" means "meaning", and with current state of the art we can't actually do anything that begins to live up to that. So talking about "semantic abstraction" tends to send one down the path towards the impracticalities of AI. |
| BenB: | oxygene: I think ooui is close to fresco's ideas, but not quite the same, stefan convinced me of that, I think ooui is one level higher in abstraction. |
| hunger: | ok, Let's start with "VECTOR GRAPHICS" and in that context "DEVICE INDEPENDENCE". |
| | rapha__ (~Raphael@p5085C88C.dip0.t-ipconnect.de) has joined channel #Fresco |
| oxygene: | BenB: above taskets? |
| stefans: | njs: I thought that this adaptability should be done server - side, i.e. without the client's need to care. (It obviously should be able to, just not required) |
| nicholas: | On that note, how important is "beautiful rendering"? |
| mourad: | stefans: I mean, designing the interface so that the server can decide (if it wants to) how to layout the widgets/ui etc |
| BenB: | oxygene: ooui rearranges the whole UI, includes windows (or the absense of them) etc. |
| njs: | stefans: that's what I meant; adapting the client's onscreen appearance, if you like. |
| | cinap agrees with njs |
| starseeker: | nicholas: I'd say very important for acceptance |
| hunger: | BenB: Could you wait with OOUI till we get to that topic? |
| BenB: | oxygene: I don't see how fresco's scene graph could map that level of abstraction. |
| stefans: | nicholas: beautiful ? Or correct (as in 'as intended') ? |
| BenB: | hunger: yeah, sure, just answering oxygene |
| nicholas: | stefans: Well, correct... as the font designer intended for example. |
| njs: | stefans: but I will observe that it's not actually clear whether that's possible -- I'm sure the server can do something, but perhaps it will require client help. I dunno. |
| | Signoff: rapha_ (Read error: 60 (Operation timed out)) |
| hunger: | Device independance is a key feature to me. |
| nicholas: | but there's more than that. Palm's, for example, don't have Open/Save buttons. Why? no filesystem. |
| | Signoff: rapha (Connection timed out) |
| stefans: | nicholas: yep, I think that is important. Or else nobody will use fresco. |
| | rapha__ is now known as rapha |
| czw: | device and resolution independence is probably a must-have. |
| nicholas: | stefans: ok then then rendering must know the DPI of the display. |
| starseeker: | czw: I agree |
| | Signoff: icebird (Connection timed out) |
| hunger: | nicholas: Can we hide the resolution inside the DrawingKit? |
| njs: | I think we should be somewhat less militant about device abstraction than we have been; we should accept that there are times when you need to find out about pixels. |
| nicholas: | hunger: no. Layout is resolution-dependent. |
| stefans: | njs: I think I agree with you that all that tasket business is a bit abstract, at least at this point. However, designing for such kind of flexibility has to be thought about upfront. |
| mourad: | In the end, what I'd like is that if the client isn't usinig specific kits (choosing the level of abstraction) that it stays general enough to be completely usable on a Palm, or a 3D workstation (single-task vs multitask, different widgets etc) |
| czw: | nicholas: not dependent on pixel-positions |
| nicholas: | czw: uh, yes it is.' |
| starseeker: | nicholas: You mean, for example, that a word processor interface can't scale down to a palm and still be usable? |
| oxygene: | njs: in that case people will be using pixels - drop vectors then |
| stefans: | mourad: yes, that makes sense. The 'basic kits' should be supported everywhere. |
| hunger: | nicholas: Sure. But can we hide that from the client? |
| nicholas: | starseeker: well it can, but you have to know what to drop. |
| nicholas: | hunger: Almost certainly. |
| hunger: | nicholas: That's what is important to me:-) |
| nicholas: | hunger: We win because the client will simply ask (something) for text layout to be done (say, when displaying a readme file.) |
| starseeker: | nicholas: Right. But isn't that an example of pixel sensivity? |
| njs: | mourad: that sounds nice. But I don't think we can say whether that's a reasonable goal yet. |
| nicholas: | hunger: but if you're writing a full word processor, then you need to know. You are a pixel sensitive application and no amount of design can prevent it; with or without Fresco. |
| hunger: | nicholas: That the server (be it up to the DKs or maybe even some other kits too) need to know the resolution is undisputed (by myself). |
| oxygene: | nicholas: actually you need some kind of layout, not necessarily pixels |
| mourad: | njs: I understand... but we shouldn't sweep it under the carpet because it comes up quite often... (picogui semantics vs device independence, taskets, ooui, ...) |
| czw: | nicholas: isn't a word processor more interested in inches and millimeters? |
| oxygene: | nicholas: text layout worked pretty good in the pre-pixel era, too |
| starseeker: | wouldn't the most relevant information to have be the physical size of the display, and density of pixels? |
| stefans: | nicholas: can we get a little more into detail as to what 'being a pixel sensitive application' actually means ? I think that's a key issue |
| hunger: | nicholas: I disagree somewhat. You need to be able to do layout in some units. Wether the server or the wordprocessor maps that to pixels is irrelevant. |
| nicholas: | czw: only when printing. In fact, in MS-Word, when you change the printer, it relays out the document according to the printer you just selected. |
| njs: | hunger: that's just not true when it comes to things like fonts; at least if you want reasonable display and suchlike. |
| oxygene: | there are applications that really work on pixels (bitmap editors) - apart from that, pixels should generally be a non-issue |
| stefans: | hunger: but that assumes that some behind-the-scene tool will compensate for the pixel rounding. That's not always possible. |
| nicholas: | Many things are pixel-sensitive. All text layout is pixel sensitive, for example. You must hint your font to the pixel grid or it will look like crap. |
| hunger: | nicholas: ... which was a bug that got fixed in recent versions of word (even though that fix is turned of by default to be backward compatible) |
| nicholas: | Placing widgets is pixel-sensitive. You want the edges to line up with the pixel grid or again, it looks like crap. |
| njs: | nicholas: that one I'm less convinced of, but maybe. |
| nicholas: | hunger: ... and the fix was to not re-layout until you actually hit print instead of changing the printer? |
| mourad: | nicholas: I know that this is a standard response, but hinting is used less an less: On my screens I switch off all hinting, I just use AA. |
| starseeker: | Are we talking about screen dimension in pixels or pixel density? |
| nicholas: | But in both of those cases the Fresco client should be able to avoid caring how the Fresco internals did the layout. |
| stefans: | nicholas: indeed. But why does that matter ? I think it matters only if you attach some constraints to the layout, i.e. if you really want to control it. Read: for an arbitrary text editor (email tool, say) the layout isn't all that important. |
| hunger: | nicholas: Nope, using a different data type. |
| oxygene: | nicholas: aligning widgets to pixel grid could be a policy in the drawing kit, or not? |
| hunger: | nicholas: Even TeX manages a non-printer resolution dependent layout. |
| njs: | mourad: raph levien says that hinting is still needed; therefore I believe it ;-) |
| nicholas: | hunger: no it doesn't. |
| nicholas: | oxygene: too late. DrawingKit happens after the layout. |
| mourad: | njs: Ah :) surprising, I think I've heard him advocating the opposite at one point... |
| stefans: | oxygene: the drawingkit ? No, because that would lead to crappy renderings, i.e. the typical artifacts you observe with unhinted text. |
| stefans: | oxygene: (for example for small details such as beveled edges etc.) |
| oxygene: | stefans: hmm.. okay |
| nicholas: | hunger: or does it? I thought it defered to the post-metafonted DPI-dependent glyphs? |
| hunger: | nicholas: It does. |
| njs: | mourad: don't think so. |
| hunger: | nicholas: The DVI-file contains the layout only. |
| hunger: | nicholas: The fonts get rendered at the right resolution and inserted once you convert DVI to whatever. |
| nicholas: | hunger: ok. fine. at high resolutions that should look fine. |
| njs: | TeX also targets very high resolution output |
| njs: | nicholas: jinx :-) |
| nicholas: | hunger: try it on a palm with 24dpi... |
| nicholas: | hunger: or, we could just decide to not support low-dpi environments. |
| stefans: | anyways, I don't think we have to nail down whether or not to abstract the pixel grid tonight. What is important is to agree on whether high quality rendering is important or not. Whether we have to hint (and thus make the layout dependent on the h/w should be a result of that requirement) |
| njs: | even for display on my desktop, TeX and PDF files look kinda wonky |
| nicholas: | hunger: that's what we're here to decide. |
| mourad: | I'm assuming that really tiny hardwate (with a couple of lines of text, or a terminal for instance) won't be supported by fresco? |
| hunger: | nicholas: I'm not arguing that we don't need to do pixel aligning. |
| starseeker: | I'd say high quality rendering is the more important thing |
| hunger: | nicholas: All I'm saying is that I prefer that to be transparent to the client (as the rest of the layout is) |
| nicholas: | hunger: I agree with you. As transparent as possible. |
| mourad: | I mean: can a base Fresco app be displayed on a text-only screen? |
| njs: | stefans: agree. I also think that if we're doing any radical shifts to the architecture -- "pulling the scene graph out of CORBA", for instance -- then it really changes what's possible and what's easy wrt rendering. |
| starseeker: | mourad: Personally I'd say that problem is solved by other tools |
| nicholas: | hunger: that doesn't mean we should hide it deliberately. Just that we should make certain they don't need to know about it. |
| njs: | mourad: no, I don't think that's a goal. |
| hunger: | nicholas: Agreed. |
| stefans: | njs: right. So lets focus on the requirements and not on the how-to-achieve-this. |
| oxygene: | njs: would be nice (wrt accessibility, too) - but it needs some non-visual widgets for grouping... |
| mourad: | njs: just making things clear... If an app is general enough, and the abstraction level high enough, what's to prevent it from running on text-only? |
| starseeker: | Maybe this is a better question - what benefits do we get teaching fresco to render at very low resolution that can't be gained by current tools? |
| stefans: | starseeker: application portability. |
| hunger: | OK, so lets nail this down: |
| njs: | mourad: I dunno. The non-existence of a high enough abstraction layer, would be my first guess. In any case, there's a reason I said "that is not a goal" rather than "we will not allow it if it turns out to be possible" |
| nicholas: | mourad: ok, i see your point, but i don't want to make it a *requirement*. |
| hunger: | * Pixel alignment should be transparent to the client. |
| hunger: | Whast kind of hardware do we need to support? |
| nicholas: | mourad: so a program that uses only menus and displays a text-file could work, but a ms-paint program wouldn't. |
| starseeker: | stefans: But if the application wants to run on such a low resolution device, doesn't that mean the client has to design the GUI to work that way? |
| mourad: | nicholas: right now a 3D app isn't required to only use 2D widgets either is it? |
| starseeker: | stefans: From what I understand small screen application design is a whole field by itself |
| hunger: | It will be a couple of years till fresco con be deployed: So a lowres PDA is not a priority to me. |
| mourad: | nicholas: absolutely! |
| nicholas: | starseeker: we should really say that the application should support certain "profiles", or somesuch. We haven't worked it out. |
| njs: | PDAs these days actually have the highest resolution of anything. |
| stefans: | hunger: 'should be transparent' is vague. I would say 'clients can ignore the pixel grid if they don't need any specific control'. |
| hunger: | stefan: OK. |
| njs: | stefans: I like that phrasing. |
| oxygene: | starseeker: you need to adapt it somewhat, but tasket like approaches can reduce the effort in the client |
| mourad: | stefans: me too |
| hunger: | * clients can ignore the pixel grid if they don't need any specific control |
| starseeker: | nicholas: OK, if the application is to support profiles (which fits the tasket model) then isn't it true that rendering at each reasolution is a different problem? |
| hunger: | So which hardware do we target? |
| mourad: | hunger: speech output? :) |
| stefans: | hunger: well, mainstream first. The stuff we are working on. |
| oxygene: | hunger: hmm.. that depends on the layer fresco wants to provide |
| starseeker: | hunger: PCs |
| hunger: | As I said before lowres PDAs are not important to me. We need a system with FPU anyway. |
| nicholas: | starseeker: sort of. A Fresco program is a composite of Fresco provided components, allowing the process of scaling to be as transparent as possible. |
| oxygene: | hunger: stop with vectors, widgets, taskets, OOUI? |
| stefans: | hunger: next comes high end hardware (so those 3D people can see whether fresco is good for them) |
| nicholas: | heh, yeah. |
| cinap: | :) |
| starseeker: | nicholas: But in application design, some parts of the program tend to be custom. Abstract things like scroll bars, menus, etc. can be provided, but things like a 3D interactive environment are custom. |
| hunger: | stefan: I would like to see high end PDA (Sharp Zaurus and upwards) supported too provided they have a FPU. |
| stefans: | I mean, 3dwm targetted an interesting audience. I believe that's where a scene graph based display server has lots of potential. |
| starseeker: | nicholas: So I'm not sure the process CAN be transparent in any nontrivial way |
| stefans: | hunger: heh, who would not :-) |
| | rapha_ (~Raphael@p5085C23F.dip0.t-ipconnect.de) has joined channel #Fresco |
| nicholas: | starseeker: then we need to be exceedingly careful about the design of our abstraction. If you have a 3d interactive environment, who needs scrollbars? A file can be written on an infinite expanse of floor. But your app just asked for a text-displayer tasket. |
| hunger: | So can we agree on a "target Hardware" of highend PDA's and up? |
| nicholas: | we'll require an FPU? |
| hunger: | That would rule out 24dpi Palms, too;-) |
| hunger: | nicholas: Definitly. |
| nicholas: | shucks. |
| oxygene: | nicholas: at least with CORBA |
| njs: | I'm not sure about 3d as being a useful target market. That'll get us gee whiz points, but will it actually help anyone? |
| hunger: | nicholas: Fresco renders with less then 0.2 FPS on a Zaurus. |
| stefans: | nicholas: well, else it's unusably slow. Should we really support integer math for the vector graphics ?? |
| oxygene: | nicholas: floats are transmitted as base10 stuff - conversion is expensive |
| starseeker: | nicholas: It depends on how you interact with the 3D environment - I've seen side scrollbars used to control X and Y rotation, for example. |
| nicholas: | well, look, freetype manages to use integer math everywhere. |
| hunger: | nicholas: Foating point math takes more than 30 times as long as on a 120MHz PI! |
| nicholas: | and they've got more work to do (and done) than we have! |
| oxygene: | hunger: fixpoint? |
| stefans: | njs: the question is whether targetting 3D will have a negative impact on other requirements |
| starseeker: | nicholas: One possibility is the Garnet model of interface design - it was possible to have the size of components depend on other components |
| hunger: | oxygene: Breaks the highend vector thingy. |
| oxygene: | hunger: implementation detail, really |
| nicholas: | starseeker: ah, we already have that. (So does Java.) |
| cow: | i like the idea of taskets as a base as they would provide simple means of providing e.g. a cylinder for (lets say) 3D representation of a scrollbar as well as a 2D conventional representation |
| hunger: | oxygene: Not really, as the datatype of the coordinate system is in the API. |
| starseeker: | nicholas: Perhaps some kind of sane defaults could be decided at each level of "zoom" for relational sizes between components fresco provides |
| njs: | I've been following Raph Levien/Tor Andersson's "fitz" stuff, and they seem to think that it might actually be possible to do real vector graphics using integers. I dunno how, seems crazy to me, but... |
| stefans: | nicholas: well, using a fixed point as FT is hard to map to h/w that actually supports openGL or somesuch, no ? |
| mourad: | Personally I don't think hardware targets are extremely important for the design: apps running on hardware that don't have FPU/3D etc, could just choose not to use certain things (vector/3D graphics) and provide an alternative implementation (on the display side) for their textlayout for instance |
| mourad: | But yeah initially we need to know where the implementation needs to be |
| nicholas: | stefans: not really, can't we just throw in a transformation matrix that does the appropriate divide? |
| njs: | FPU is kinda hard to avoid, what with matrix multiplies at the layout level. |
| hunger: | mourad: I am asking since wether we need 24dpi displays or not does matter. |
| starseeker: | nicholas: I don't know if we want to decide this or not at the fresco level, but we might take the position that at each resolution there is some ideal "useful" size for a given component, and use that size unless explicitly told otherwise by the program |
| mourad: | hunger: for the implementation, yeah, but for the design? |
| stefans: | nicholas: well, we have to cast the int to a float, somehow. Ideally that can be done by some sort of reinterpret_cast, but I don't know whether that's possible... |
| nicholas: | starseeker: well, we currently follow the TeX model, what with alignment and relational sizing and whatnot. We don't consider components with respect to the screen. In fact, we assume, in Fresco, that all screens are equal. |
| nicholas: | stefans: hm... yes... |
| stefans: | nicholas: probably only if we designed our fixed point data type for a particular h/w :-) |
| hunger: | mourad: See the pixelgrid discussion. |
| | stefans needs to look up the ieee float specs |
| starseeker: | nicholas: Isn't that a bad assumption when it comes to intracting with components at unusual resolutions? |
| mourad: | hunger: I'm assuming there's apps that don't need access to the pixelgrid... |
| nicholas: | starseeker: naw, really? why do you think i'm here arguing it? :) |
| hunger: | mourad: I was trying to point out that this might influence the design. |
| starseeker: | nicholas: Ah, of course :-). But we can still have resolution and pixel independance as far as the clients are concerned, if they use fresco components |
| stefans: | ok, so did we get a prioritized list of h/w to focus on ? |
| starseeker: | nicholas: We just have to make intelligent choices |
| nicholas: | starseeker: exactly. you got it. |
| stefans: | what are the niches fresco would be well received, i.e. where conventional display servers fail ? |
| mourad: | 1) current 2D workstations 2) 3D 3) PDA's 4) everything else ?? |
| hunger: | * Fresco will target PCs, high end (3D) hardware and PDAs with FPU and a good screen last. |
| starseeker: | nicholas: Then I'm a little confused - why all the fuss about pixels? Fresco has to deal with them at some point anyway, since the screen is made up of them. Are we arguing about where to deal with them? |
| | _cow nods hunger |
| BenB: | stefans: I think conventional display systems fail misreably on modern hardware :) |
| | starseeker agrees with hunger |
| BenB: | it has so much to offer, and all unused. |
| BenB: | I mean modern PCs |
| nicholas: | starseeker: yes. Previously, we had designed such that nobody responsible for layout was allowed to know about the final display. |
| stefans: | yeah |
| | Signoff: ShelterIt ("Leaving") |
| nicholas: | ok. that's settled then. |
| mourad: | I've heard there's now hardware acceleration of Glyphs/fonts :) Matrox i think |
| stefans: | hmm, what about location transparency ? |
| njs: | I still don't see how 3D is that high a priority, but whatever, we can figure out how to support current desktops and then see if that needs revisiting :-) |
| nicholas: | mourad: Really? I'd need to look at that... |
| nicholas: | oh, location transparency. |
| njs: | stefans: you mean, the ability to run clients from anywhere? |
| hunger: | I guess this was the SCALABILITY discussion then;-) |
| hunger: | Let's get on to LOCATION TRANSPARENCY: |
| stefans: | njs: well, the ability to have some objects be either in the server or the client. |
| starseeker: | nicholas: Oh, I see. |
| starseeker: | nicholas: I guess I've made it to the starting point :-/ |
| njs: | stefans: ah. Seems to me that should mostly be aon a case-by-case basis? |
| hunger: | We definitly need network transparnecy with client and server running on different system. I guess that's undisputed, isen't it? |
| nicholas: | starseeker: and it's not exactly some sort of easy fix either. The scene is layed out once, then rendered by different screens... so... we'd need to make it such that we do layout once per screen. |
| stefans: | njs: yes, transparency in the generic sense we have now can probably be dropped. |
| stefans: | hunger: right |
| nicholas: | hunger: right. |
| BenB: | njs: a main advantage of location transparency is that you don't need to rewrite or even rearchitecture your whole app when you change the location of objects later. |
| mourad: | stefans: you mean the client should be able to send some code to the server? |
| starseeker: | nicholas: Is the concern that would be too expensive, or that it's a major change in the system? |
| czw: | hunger: both different systems and different processes |
| BenB: | njs: and we do that a lot, not? |
| hunger: | czw: Of course. |
| nicholas: | starseeker: very major change to the system. Nearing rewrite status. |
| njs: | BenB: except that in practice you usually do, because pretending that local and remote are the same doesn't make it so. |
| stefans: | mourad: no, 'sending code to the server' sounds like an implementation serving such a requirement. But there are others... |
| BenB: | (i.e. we can'T decide, where the HTML rendere is supposed to be= |
| hunger: | Do we need to be able to have the server distributed over several systems? |
| starseeker: | nicholas: Wow. I didn't know it was in that deep. |
| nicholas: | starseeker: neither did I until I tried it :( |
| njs: | BenB: ah, yeah, in some cases that's helpful. |
| stefans: | distributed server ? No ! |
| hunger: | What about student/teacher scenarios? |
| czw: | hunger: p2p fresco? :-) |
| nicholas: | czw: lol |
| mourad: | hunger: good question, you're thinking about some kind of multi head? |
| hunger: | What about coupling several servers into one "virtual server"? |
| njs: | stefans: the trader scenario is actually sorta like that; "Hey, server, gimme an HTML renderer" "err, well, here, talk to mozilla" |
| stefans: | hunger: er, is that really on our priority list ? I mean, in what way is that at all related to display servers ? |
| starseeker: | nicholas: Ah. I don't suppose Z would have helped that problem. |
| | jon has left channel #fresco because () |
| hunger: | stefans: I'm asking everyone;-) |
| nicholas: | starseeker: Z? you mean a depth-axis? we already have one. ?? |
| stefans: | njs: er, yes. I don't see your point, though, sorry. |
| njs: | stefans: <stefans> distributed server ? No ! |
| starseeker: | nicholas: No - mapping out the arch with the Z language |
| hunger: | stefan: I think it would be nice to tie up several of my PCs and have a huge virtual desktop over all of them. |
| nicholas: | One display server runs one display, yes? |
| njs: | nicholas: define "one display"? |
| nicholas: | starseeker: not familiar with Z. At this point, any arch work would help. |
| starseeker: | nicholas: Rather then coding, mapping out the ideas in logic. |
| nicholas: | njs: well, I'm temped to say one physical monitor, but that's not quite right. A two-head system where one screen pans over both is still one display. ok? |
| hunger: | stefan: Currently we should be able to do somehitng like that thanks to CORBA and it is a "distributed server";-) |
| stefans: | nicholas: yes, I think so. And gets input from one console (set of input devices). |
| njs: | nicholas: yeah |
| starseeker: | nicholas: Then when logic is clear, code it up. Or at least I think that's how it is supposed to work |
| nicholas: | starseeker: or like UML. |
| stefans: | hunger: well, isn't that by accident ? I mean, it wasn't really designed in, or was it ? |
| | njs has two monitors on his desk, so you can count on him to champion multihead :-) |
| nicholas: | starseeker: yes, this is what I'm saying should've happened a long, long time ago before the code came. :( |
| njs: | hunger: and will it really work right? :-) |
| starseeker: | nicholas: yes, I think that's another technique. |
| cow: | stefans, is this a current hard limit? |
| | Signoff: rapha (Connection timed out) |
| hunger: | stefan: Is it an accident to have a nifty feature? |
| stefans: | _cow: ? |
| BenB: | hunger: I think it would be neat to have a "smart display", a computer devoted to rendering only, basically a terminal, but severl onf them togehter. |
| starseeker: | nicholas: So maybe, if we're looking at rewrite, this is the time to do it? |
| nicholas: | Notice that i never said 1 program to 1 display or anything. :) |
| stefans: | hunger: no, but now we are talking about requirements. :-) |
| cow: | stefans, he server serving only one input/output set? |
| BenB: | hunger: imagine fresco built into your TFT :) |
| hunger: | njs: Who knows? |
| nicholas: | starseeker: we'll see. Let us continue requirements analysis for now. I expect we'll be hashing all sorts of stuff out over the mailing list in the near future. |
| stefans: | _cow: yes |
| hunger: | stefan: So you say multi-server is not a requirement. |
| starseeker: | nicholas: Right. Thanks for explaing it :-) |
| hunger: | stefan: What about multihead? |
| cow: | stefans, not ideal :) |
| | rapha (~Raphael@p5085C0EF.dip0.t-ipconnect.de) has joined channel #Fresco |
| stefans: | hunger: well, unless I misunderstood the sense of that term, no. |
| stefans: | hunger: multihead ? Yeah, absolutely. |
| hunger: | stefan: I do think multihead is a must. |
| stefans: | hunger: but those 'heads' are coordinated by a single server (how it does that doesn't matter tonight). |
| njs: | multihead quickly gets into complicated issues (what if the monitors have different resolutions or color profiles?) that we don't want to worry about now, but definitely they should be worried about sometime. |
| nicholas: | njs: it's good to deal with that now. |
| cow: | nfs, fine |
| hunger: | * Fresco will support multihead. |
| njs: | nicholas: I mean, "in this meeting" |
| hunger: | OK, that's settled;-) |
| nicholas: | njs: because if they have different DPI's in a word processor, doesn't that mean different layout on each screen?? |
| nicholas: | njs: am I setting myself up for a serious mess? |
| hunger: | Multiserver is an extension of that idea... we will not support that? |
| stefans: | njs: how is that different from having the same app running on different display servers (serving on different monitor types) ? |
| cinap: | hunger: the lainos-people will love it... |
| nicholas: | njs: perhaps we should allow multihead only when the DPIs match? |
| cinap: | hunger: ;) |
| mourad: | cinap: lainos? |
| stefans: | hunger: sorry, but I don't see how 'multi server' is just an extension from 'mult head'. Again, as I understand that term. |
| stefans: | nicholas: heh, sounds like a deal :-) |
| oxygene: | nicholas: hmm.. how do these layouts differ - mostly by rendering decisions in font hinting, yes? |
| hunger: | nicholas: We are supposed to be device independnet, aren't we? So requiring the same resolution sounds starnge to me... |
| stefans: | nicholas: (where 'match' could be relaxed to 'are compatible') |
| maus-: | im a total newbie, but i couldn't think of a use for this multiserver-stuff |
| mourad: | stefans: I think he means, having two different machines act as two heads of one "display" |
| njs: | nicholas: no, I can't afford to upgrade my smaller monitor right now, so that's out ;-) |
| oxygene: | nicholas: weird restriction |
| cinap: | mourad: they want to create a user-enviroment like in the anime "serial experiments lain" |
| nicholas: | oxygene: sure! Or because you have a 1in button and the pixel-grid alignment of its edges is different across the two displays. |
| hunger: | stefan: Yeap... what mourad said. |
| mourad: | cinap: fun :) |
| stefans: | hunger: oh, device independent ? Did we really say that ? I thought we disputed that in the first point. |
| cinap: | mourad: jup... |
| oxygene: | nicholas: I took the font as example because it's a common issue today |
| nicholas: | oxygene: it's not that surprising. You must allow us to pretend that your two heads are interchangable. Why not? |
| njs: | nicholas: because so often they just won't be in practice. |
| hunger: | stefan: Basically that meens exporting the scenegraph... which would be handy in a student/teacher scenario and other situations too. |
| njs: | Think of all the professional 3d modellers who have one super-fancy display and one low-res one. Or giving presentations with a laptop and projector -- projectors have way lower resolution than your laptop screen. |
| oxygene: | nicholas: could objects be layouted twice - once in the scene graph, adding hints to the stream down to the DK/Console which help how to handle such corner cases? |
| stefans: | njs: well, there are always ways: you may have your application talk to two display servers (one on each monitor), or you may settle on the lesser resolution. |
| nicholas: | njs: I agree... but would we be any worse off than our competitors? |
| nicholas: | njs: well, those are totally two displays. |
| | stefans agrees |
| nicholas: | njs: projector and screen is not multihead. |
| njs: | nicholas: mm, okay, perhaps |
| njs: | nicholas: you should be able to address them both with one display server, though, I think. |
| nicholas: | njs: but, duh, we'd need multiple displays per server then. |
| stefans: | 'multi head' would mean to fool the user into thinking that the two displays are just one big |
| hunger: | nicholas: Apple works with screens in different resolutions/color depth. |
| nicholas: | njs: so one scene graph, multiple renderings. |
| nicholas: | hunger: seriously? man, Apple is so cool!! |
| njs: | shrug Apple's customers need that :-) |
| hunger: | nicholas: At least they did when they did a presentation about the first power macs in 199x... |
| stefans: | nicholas: and again, multiple renderings (with different resolutions) is only hard if the app has specific requirements such as high quality fonts. |
| oxygene: | hunger: amiga worked with screens in different resolutions/color depths per rasterline shrug |
| BenB: | I think that most multihead setups have different resolutions |
| nicholas: | njs: but apple cheats, don't they? "0.1units" = "1px" for apple. |
| nicholas: | njs: so you can't get a 1in bar on an Apple multihead display with different resolutions, right? |
| BenB: | in my current case, that's a TV and a monitor. or one big TFT and 2 smaller left and right. |
| njs: | nicholas: I dunno. |
| nicholas: | See, multihead is easy if your rendering system is pixels. |
| nicholas: | So we have a choice: multihead support versus real-world units. |
| hunger: | We are getting off topic... |
| czw: | using standard apps like quicktime on my mac, it's not resolution independent (screen vs tv) |
| | stefans thinks 'real world units' is a must |
| hunger: | Do we want multiserver? Seems like the tenor is No. |
| nicholas: | hunger: no. |
| cinap: | hunger: i'm skeptic about security and performans from the milti-server-idea... it's cool... no question... |
| nicholas: | hunger: well, wait. define multiserver. |
| | stefans agrees |
| njs: | what does "multiserver" even mean? |
| stefans: | again, not making it a requirement doesn't imply it won't be possible |
| nicholas: | hunger: 1 program should be able to connect to multiple servers, just like in X... |
| hunger: | Do we want to couple several servers (running on multiple hosts) into one "virtual server". |
| stefans: | nicholas: nah. That is always possible (and doesn't even touch the fresco architecture) |
| nicholas: | hunger: nope. |
| stefans: | hunger: ah. That one I can clearly refuse :-) |
| mourad: | lol :) |
| hunger: | Basically a "multiheaded" environment with each head being managed by its own server. |
| BenB: | hunger: I'd find it nice, and may find applications for it, but I don't feel strongly about it. |
| hunger: | * No multiserver with the above definition. |
| oxygene: | sounds like a big proxy |
| njs: | hunger: no, that seems silly for now |
| | cinap feels like BenB |
| stefans: | hunger: well, but 'multi head' implies a single big scene graph distributed across multiple monitors. That should be managed by a single server |
| stefans: | in fact, I would say 'one scene graph per display server'. |
| stefans: | at least to start with. |
| nicholas: | stefans: agreed. |
| mourad: | okay |
| hunger: | OK, then let's decide on that... |
| hunger: | * One scenegraph per server |
| cinap: | ok |
| oxygene: | and one server per scenegraph |
| cow: | stefans, right, i still want to drive all 3 'graphic cards' with one server to render one scene.. anyways |
| stefans: | can we come back to the location transparency question please ? :-) |
| | hunger sues * so he can find the decissions easily later on. |
| nicholas: | oh, the big one. To CORBA, or not to CORBA? |
| oxygene: | stefans: wrt njs' mails? |
| hunger: | stefan: So far we decided that the server will run ine one machine and a client can connect from another. |
| stefans: | oxygene: yes |
| BenB: | hunger: sounds like X :) |
| stefans: | nicholas: not yet. I think CORBA (or not) could be the answer to the requirements we'll have to settle on |
| nicholas: | BenB: that's because X got it right. |
| hunger: | Do we need to allow for clients being distributed over several hosts? |
| | hunger thinks not. |
| nicholas: | stefans: oops, sorry |
| stefans: | hunger: er, how does that affect fresco ? |
| nicholas: | hunger: huh? |
| mourad: | hunger: why not? |
| | Signoff: rapha_ (Connection timed out) |
| BenB: | hunger: I think you need to be more specific.... |
| BenB: | hunger: do you mean app-app cooperation or ... |
| stefans: | hunger: I mean, if you connect from different addresses to the display server, you'll need different 'server contexts', so the server thinks of you as multiple clients. Whether they are just one (logical) or not doesn't matter. |
| hunger: | mourad: Lets rephrase: Do we need several hosts to talk to the server as one "application" |
| BenB: | display components (ala HTML renderer) |
| stefans: | hunger: why should the server care ? |
| nicholas: | hunger: oh no, are we discussing the definition of application? |
| hunger: | stefan: That's what I meant. |
| stefans: | hunger: what ? |
| hunger: | stefan: I'm trying to come up with requirements we have so that we knwo what we want when we get into the CORBA or not discussion later. |
| nicholas: | stefans: so a client is an application. |
| njs: | hunger: in my model, they'd each have their own connection to the server, but if they share caps freely, then any of the connections can do the same thing. |
| hunger: | stefan: hunger: I mean, if you connect from different addresses to the display server, you'll need different 'server contexts', so the server thinks of you as multiple clients. Whether they are just one (logical) or not doesn't matter. <hunger> stefan: That's what I meant. |
| stefans: | nicholas: hmm, ok |
| nicholas: | njs: hm....... so I could give "permission" to another program to goof with my window on my behalf? |
| stefans: | hunger: the server shouldn't care whether the different contexts it serves are coming from one address space or not, or whether they both talk to each other |
| nicholas: | njs: s/program/client/ |
| njs: | nicholas: if you felt like it. |
| stefans: | hunger: and for that matter, neither does CORBA care |
| hunger: | So is a client an applicaiton? |
| | stefans doesn't care how it is called |
| njs: | I would argue that for the server, a client is a connection. |
| starseeker: | Is this were we get into several programs making up one "interface" for the user? |
| stefans: | njs: fine with me. |
| nicholas: | Yes. |
| hunger: | stefan: We are going to have a CORBA or not debate I think... so wether CORBA can do it or not is not important to me at this point. |
| stefans: | njs: but whether that coincides with 'socket connection' or any other tcp related term is yet to discuss ;-) |
| njs: | stefans: right :-) |
| hunger: | stefan: What do we need? |
| nicholas: | stefan: because you've just precluded the possibility of composition involving components implemented on different machines in the network. |
| stefans: | nicholas: composition of what ? |
| nicholas: | stefan: composition of my GUI. |
| stefans: | nicholas: huh ? Did I ? I didn't mean to. |
| njs: | nicholas: what do you mean "components implemented on different machines"? |
| nicholas: | stefan: I think you did. Did I misread you? about how one client is one connection? |
| nicholas: | njs: my application is on machine "a" but the embedded word document viewer is only available on machine "b". |
| mourad: | okay, so a UI can be made up from components running on different machines? |
| njs: | nicholas: I think that's a totally separate issue. |
| stefans: | nicholas: right now we use that model, right ? One app ('client') holds one 'server context'. It's possible to hook different scene graph chunks up into each other, thus having 'graphical embedding'. |
| starseeker: | nicholas: Is this a reasonable scenario? I want a GUI for my Maxima program, and to build it up I run the framework interface on my machine, a plotting component on another machine, and a PDE package interface on a third - building them all into one GUI which displays on my desktop? |
| nicholas: | stefan: so two clients (different machines) can't come together to provide one ui? |
| hunger: | nicholas: Is the embedded word processor it's one client/application/connection or not? |
| nicholas: | stefans: oh, right. sorry. :) |
| stefans: | nicholas: I don't see any problem with that. Of course, we'll have to talk about security and stuff... |
| nicholas: | starseeker: thus far, Fresco can handle it just fine. |
| nicholas: | starseeker: I mean, as implemented today. |
| mourad: | okay |
| mourad: | what about finding the server? |
| starseeker: | nicholas: Right. I was just trying to illustrate the behavior you were arguing for (I think?) |
| nicholas: | hunger: Uh... no. |
| nicholas: | starseeker: yes. |
| BenB: | it's still unclear where the HTML renderer (or the like) is supposed to be, or if we can even decide/require that offhand. |
| starseeker: | nicholas: It took forever for me to get my head around that. It still feels fragile, even though I suppose there's no reason it should be |
| hunger: | nicholas: It's not? How do you start it then? |
| nicholas: | starseeker: I'm imagining public document viewers (translators even?) that you could plug in to your UI over the internet. (Hey web, move over!) |
| nicholas: | hunger: the servercontext is my program. what's embedded doesn't need a servercontext. |
| stefans: | in X, there is a fixed set of 'objects' the protocol knows about. Fresco is much more extensible. I believe this extensibility implies some form of location transparency. |
| BenB: | I may want to have a PNG renderer (or whatnot) on the display server, but I won't want to have Mozilla running on a pure terminal. |
| starseeker: | nicholas: Our security would have to be darn good for me to trust something like that |
| hunger: | nicholas: How do you have it connected? |
| nicholas: | hunger: I haven't decided. Thus far, it's a CORBA node in my scene graph. After this meeting? Who knows. :) |
| njs: | I think the ability for apps to cooperate like that is nice (though not, I think, as important as the original opendoc/fresco types thought it was), and will probably come out for free if we aim for other desirable features like composability. |
| nicholas: | starseeker: indeed, but CORBA fails to offer us the necessary security. That being a major issue against CORBA. But we're not on that discussion yet. |
| nicholas: | Fresco was originally up against OpenDoc as a compound document architecture. |
| | Signoff: icebird_ () |
| hunger: | nicholas: I think a special "window" to embedd some other client into an application is a reasonable way to go. |
| starseeker: | nicholas: OK. My other concern - are there any application environments out there that could actually make use of such an idea? |
| nicholas: | I'm curious to know whether any of that is going to live on. |
| stefans: | nicholas: yes, and I still think that's a goal (not the competition, but the feature :-) |
| njs: | nicholas: I don't think anyone has proposed changing it |
| hunger: | nicholas: That way the embedded client would get its own servercontext and the server has better control. |
| nicholas: | starseeker: well, read about CDAs, compound document architectures. Even MS-Windows does it with OLE and now COM. |
| hunger: | starseeker: Kparts, bonobo in the free SW world. |
| nicholas: | hunger: ok. we should consider that at some point (soon). |
| njs: | I note that the gnome folks have decided that bonobo was stupid and are killing it |
| nicholas: | lol |
| starseeker: | hunger: Ah. So they would migrate successfully to this type of system? |
| starseeker: | njs : Yep :-) |
| oxygene: | njs: hopefully they kiill the entire project because of stupidity shrug |
| | rapha is now known as rapha|zZZzz |
| hunger: | Can do agree on this: |
| njs: | (not just because it sucked technically, but also because they decided that from a UI point of view, mixing up apps like that was extremely confusing.) |
| starseeker: | nicholas: My main concern is if we don't have some idea in the back of our heads how all the work out there now can migrate without immense pain to Fresco, we get ignored. |
| stefans: | what about extensibility ? New types, etc. I believe that fits into the 'location transparency' issue, I'm just not sure how. |
| starseeker: | nicholas: I figured KDE would like it, given what they've done with koffice and konqueror, but I wasn't sure about Gnome. |
| njs: | starseeker: note that Gnome and KDE didn't exist just a few years ago. And think about how many GTK+/Qt apps there are now... I don't think migration is actually critical. |
| nicholas: | starseeker: that's another point. Fresco has claimed in the past that backwards compatibility was impossible due to the complete redesign of the software involved, therefore there should be no attempt to provide support for legacy applications. |
| hunger: | A client will hold one "connection" to the server (call it servercontext if you want) and can embedd other clients through some special graphic which holds its own "connection"? |
| njs: | as for providing support for legacy applications, that's an entirely different matter; all you really need is a vnc viewer. Better would be to have a rootless X server. But neither really depends on anything special from the Fresco server. |
| hunger: | starseeker: At least not at this point... |
| starseeker: | njs: Yes, but the momentum and work put in in those few years is monumental. |
| stefans: | hunger: er, is it really the client that 'can embedd other clients' ? |
| oxygene: | hunger: that would indicate some serialization of the scene graph as render stream which can be further processed |
| BenB: | hunger: doesn't that break the whole composition idea? |
| starseeker: | nicholas: Eeeep. |
| nicholas: | hunger: should we have a differing notion of clients and components? |
| njs: | starseeker: sure. But they've thrown away most of that work already; that's how it works in software :-) |
| starseeker: | njs: Gnome has. AFAIK, KDE has actually stuck with it for quite a while now. Or did I miss something? |
| hunger: | stefans: well, someone requests something else to be embedded. I think that a client will do that most of the time, don't you? |
| njs: | hunger/nicholas/stefans: I think we're getting confused about this. Talking about connections in a vacuum, with no networking architecture around them, doesn't make any sense. |
| | nicholas is with njs. |
| hunger: | nicholas: I think it would be better if a client wouldn't need to care wether it is run in a window or embedded. |
| stefans: | hunger: hmm, right, the request comes from the client. But the embedding is really about scenegraphs, no ? |
| nicholas: | hunger: yeah, but that's not gonna work... |
| BenB: | njs: well, i think it's important to define the requirements fot eh archtiecture... |
| starseeker: | hunger: But mightn't the client want to present a different interface for embedded vs. standalone? |
| njs: | BenB: yes, but we're not doing that :-) |
| stefans: | nicholas: what's not going to work ? |
| nicholas: | stefans: pretending that clients and components are indistinct. |
| stefans: | nicholas: you mean the application has to care about whether it is stand alone or embedded ? |
| nicholas: | stefans: yes. |
| starseeker: | stefans: Whether is has to or not, some of them probably will |
| stefans: | nicholas: hmm, I don't see that. But that's dragging us even further off topic. May be another time (or later). |
| hunger: | nicholas: It needs to present its menu, statusbar, etc. differntly. |
| BenB: | njs: I think that my question of where the componets actually practically are, would be part of those requirements. |
| hunger: | nicholas: I think we could handle that in a generic way so that both embedded and non-embedded usage is possible. |
| nicholas: | hunger: OLE worked by taking the embedded apps menu bar and adding it to the parents menubar. Similarly with the statusbar (multi-part status bars). |
| nicholas: | hunger: but we need some decision on how to handle it. |
| stefans: | hunger: well, the server just provides some 'context' into which the client can hang these resources. Whether they are global or embedded shouldn't make a difference. |
| hunger: | stefans: That's what I was trying to say in my laymen's terms. |
| mourad: | okay I think everyone agrees: * embedding is a good thing to have |
| stefans: | nicholas: I'd keep that open. I think it would be good to think further about it, but I don't believe the ramifications are as critical as the other questions |
| stefans: | mourad: thanks :-) |
| | BenB gets tired, 1:30 here. |
| hunger: | So no consnsus on: |
| hunger: | A client will hold one "connection" to the server (call it servercontext if you want) and can embedd other clients through some special graphic which holds its own "connection"? |
| nicholas: | stefans: if nothing else, it changes how a client connects. (How can I embed a program that doesn't know it's supposed to be embedded? It'll simply connect to the server as a standard app!) |
| hunger: | But * embedding is good? |
| njs: | hunger: I just don't know what you're talking about, if I'm supposed to pretend that we have no other network architecture in mind. |
| stefans: | nicholas: indeed, good point. That needs some special support. |
| stefans: | nicholas: may be just a special convention as to how to start embeddable applications to be really embedded. |
| mourad: | we are talking about requirements still, right... lets' fill in the details later |
| hunger: | Is there consensus on "We want embedding but need to think further about the details"? |
| nicholas: | stefans: sure. and how a loading embedded application will inform the server that it is the requested resource. |
| nicholas: | hunger: i vote yes. |
| mourad: | yes |
| | cinap too |
| stefans: | ok, so I think some form of embedding is a requirement, albeit the exact mechanism to support that isn't designed yet. |
| stefans: | heh |
| hunger: | OK. Let's move on then... |
| njs: | maybe "Embedding is a nice thing to have, but the details will depend on other aspects of the architecture" |
| nicholas: | mind you, CDA (OpenDoc) fell flat on its face... |
| stefans: | nicholas: right |
| hunger: | * Embedding is a nice thing to have, but the details will depend on other aspects of the architecture |
| nicholas: | mind you twice, so did Fresco (OpenDoc's competitor)... |
| stefans: | nicholas: heh |
| starseeker: | What's next hunger? |
| hunger: | What about FLEXIBILITY/EXTENSIBILITY? |
| stefans: | hunger: yeah, thanks. |
| nicholas: | MODULARITY? |
| hunger: | How can a application extend what is there? |
| BenB: | yes |
| nicholas: | 1. by providing an embeddable component? |
| starseeker: | In what sense? Custom rendering? |
| stefans: | by that I mean what kind of data should be exchanged between client and server ? object model ? type system ? How is the interface (protocol) be defined ? |
| BenB: | nicholas: how do other apps discover and use it? |
| mourad: | ah? like a tree widget :)? |
| nicholas: | BenB: uh oh. :) |
| BenB: | nicholas: where does it live? |
| nicholas: | BenB: spaghettios! :) |
| BenB: | heh |
| hunger: | Can an application create new graphics (that are not built up from existing ones)? |
| cinap: | hunger: i think this is like embedding... providing it's own objects... like the clock-demo... but maybe not on the scene-graph-layer... |
| njs: | stefans: that's not a requirements question |
| stefans: | hunger: that one I would rule out. Because it requires a distributed scene graph. Does it not ? |
| starseeker: | hunger: I would say yes - existing ones may not be comphrensive enough |
| njs: | stefans: you can't infer that sort of thing from first principles :-) |
| stefans: | njs: ok, you cought me :-) |
| hunger: | cinap: This heavily influences the communication architecture. |
| njs: | stefans: :-) |
| starseeker: | hunger: opps, nevermind :-) |
| rohara: | is this extensiblility of the client or the server or both? |
| hunger: | stefan: I'm strongly leaning that way too, if only for securioty/robustness reasons. |
| stefans: | hunger: ok, you could upload some script, so it's not entirely impossible |
| cinap: | for the requirements: * extensibility? yes! of course! |
| nicholas: | (for example, if they need custom rendering, what makes it necessary that they have a Graphic? why could they simply use a Path?) |
| njs: | I think apps do need to be able to, say, add new widgets; this should happen very rarely, but sometimes it will be necessary. I think the proper way to do this is to have a server-side widget that acts as a slave to the client, and insulates the scene graph from the nastiness of remoteness. |
| hunger: | stefan: That's using an existing graphic... ;-) |
| nicholas: | Graphics are for custom Layout. |
| stefans: | nicholas: hmm, paths can only be drawn inside graphics |
| hunger: | njs: We are not yet talking about widgets. |
| njs: | (i.e., it should be possible, but as something bolted on later. For the basic design, we can and should assume that the scene graph lives entirely in the server.) |
| nicholas: | stefans: Berlin::Path, yes, but not Figure::Path. Figure::Path is a Graphic that draws a Berlin::Path. :) |
| stefans: | nicholas: whoever wants to draw a path needs a DrawingKit |
| | TheFifthPope (~axis@dhcp024-209-224-088.cinci.rr.com) has joined channel #fresco |
| hunger: | So we will not support client-side graphics? |
| | cinap agrees to njs |
| stefans: | nicholas: indeed. But if you are requesting a Figure::Path you are talking about composition, which is not what hunger asked about. |
| nicholas: | right. My comment was simply that the only need for a custom Graphic is for custom Layout. |
| stefans: | hunger: right. I believe that's our first big change. Isn't it ? |
| BenB: | hunger: the question is: do we have to? |
| njs: | hunger: not directly, seems to be the consensus? I've certainly been advocating that for months now :-) |
| cinap: | hunger: of course... but maybe not on this generic level like the scene-graph... maybe some proxy-graphic... |
| hunger: | * No clientside graphics. |
| nicholas: | Hold on... |
| BenB: | hunger: wait... |
| mourad: | :) |
| hunger: | BenB: Sorry, I don't get what you are trying to say. |
| BenB: | hunger: there were cases where I had to implement graphics to do what I need, ... |
| nicholas: | Can we make client-side graphics a possibility for when the user allows them? Suppose the user understands that they're allowing something insecure, but will allow it anyways. hm? |
| stefans: | well, we may still have some 'direct rendering' infrastructure, but that one would bypass the 'official' communication protocol (CORBA or not) |
| BenB: | because the server simply didn't provide a way to do it. |
| hunger: | BenB: Like what? |
| BenB: | hunger: simple example: reaction to key presses (atm) |
| stefans: | BenB: the current server is totally incomplete, don't forget that. |
| BenB: | stefans: yes, sure. |
| BenB: | stefans: but at one point, you argued (IIRC) that the client should be able to react to key presses directly. |
| nicholas: | Client-side graphics are good for me, purely for debugging. Could I simply have written my own small Kit? |
| hunger: | BenB: clientside graphics are a hazard for robustness... |
| stefans: | nicholas: good point. Well, can that be restricted to the local case (similar to Xshm ?) |
| njs: | nicholas: I don't see the point of that. a proxy graphic approach needn't be insecure, and it makes life simpler to not have to support any other way of doing client-side graphics... |
| BenB: | hunger: I realize that. |
| stefans: | BenB: yes, and I'm still thinking that event handling may be done by the client. |
| ryanarn: | is someone logging this meeting? It is out of my league but I'd like to read it later. |
| | cinap thinks of building something like a seperate and protected extension layer |
| nicholas: | stefans: perhaps instead, we should allow users to register their own kits. |
| hunger: | ryanarn: Yes. |
| ryanarn: | hunger: thanks |
| nicholas: | njs: I changed my mind, i don't want clientside graphics again. But I do want user-provided Kits. :) |
| BenB: | but still there were a ton of things the server can't do and the app wants to do. can we be sure ther won't be any of those? |
| stefans: | nicholas: hmm, tasty. You may kits that provide graphics with back-ports designed for the client to get in ? |
| hunger: | nicholas: That brings in the same robustness problems. |
| stefans: | s/may/mean/ |
| BenB: | (after the server is complete) |
| nicholas: | stefans: well, Kits that contain those fancy Foomatic Graphics my client needs. |
| nicholas: | hunger: no worse than the rest of Fresco code. |
| stefans: | nicholas: oh, sure. |
| stefans: | well, so we are talking about extensibility. |
| nicholas: | extensiblity through Kits is something we got Right. |
| stefans: | kits can provide new implementations of known interfaces. Can they also add new interfaces ? |
| stefans: | nicholas: yes ! |
| njs: | nicholas: I suppose, thought it doesn't seem to be a common need, or a big deal to support. (Kits are currently extensions anyway, why not let people drop in their own if they want, it's not like we run as root...) |
| hunger: | stefan: Sure, you can always add your own Kit:-) |
| njs: | nicholas: I think we agree :-) |
| hunger: | Consensus on "No clientside graphics but the suer should be able to install kits for himself"? |
| BenB: | the problem is that the app has no access to the server. |
| stefans: | njs, nicholas, hunger: I think the key issue here is that the protocol has to be designed to support extensibility. It needs some form of type system / object model. |
| nicholas: | BenB: That's not a problem, that's the good part! |
| nicholas: | BenB: that allows the user to decide whether to accept the potentially unsafe code for themselves. |
| stefans: | heh, I agree |
| BenB: | if we have display and app running on different machines, there is no practical way (in the general case) to install anything app-specific on the display |
| stefans: | BenB: right. But don't forget that the user is local with respect to the display server, not (necessarily) the app. |
| nicholas: | There's a worse issue. |
| nicholas: | Should we allow Kits to run on foreign computers? |
| stefans: | BenB: so if he wants to run an app that has special requirements, he can upgrade his display server. (such as installing a new mozilla plugin) |
| nicholas: | (Say the Kit is written for Solaris, but my server is Linux.) |
| stefans: | nicholas: 'foreign' ? |
| BenB: | stefans: yes, that's important for customization to user needs (did you mean that?), but it doesn't help apps with extending server missing functinality. |
| nicholas: | Now what do we do? Who loads the Kit? Servers load kits. But we already decided against allowing servers to group together and form 1 virtual server. |
| njs: | I think it should only be the very most nasty apps that need custom kits, and everyone should glare at them a lot. Like, what you'd think of an X app that required you to install a special server extension. |
| BenB: | stefan: I disagree that you can force the display to have certain extensions just to use a certain app. |
| | ryanarn is now known as ryanarnZz |
| hunger: | We decided on "one scenegraph per server", so the kits providing those graphis need to be with the server. |
| stefans: | njs: of course, the assumption is that the set of available kits is already fairly complete |
| BenB: | stefan: this will end up being a hassle, then you can just as well have the app on the local machibe. |
| stefans: | njs: (i.e. well tested and all) |
| njs: | stefans: right |
| stefans: | nicholas: what do you mean by 'written for solaris' ? |
| oxygene: | stefans: compiled on for solaris/sparc64 instead of linux/arm |
| stefans: | nicholas: I think that there should be a specific and explicit procedure to install new kits for a given server. |
| nicholas: | stefans: I was worried about a Kit running on computer 'a' collaborating with a Fresco server on machine 'b'. |
| njs: | It seems to me that something like mozilla won't require a new kit anyway, since it probably won't need any new server side graphics, it could just be a client that interacts with other clients, and creates graphics in the server on their behalf. |
| oxygene: | stefans: no sources available |
| stefans: | nicholas: the user has to be aware of that, if only it is a potential security issue. |
| nicholas: | stefans: ok, so then it simply won't be possible. That's fine. |
| stefans: | oxygene: oh, binary (in)compatibility |
| stefans: | nicholas: I thought kits were running in-process. Isn't that so ? |
| nicholas: | stefans: Yes they are. So that's fine. |
| stefans: | nicholas: yes |
| BenB: | njs: I'm not so sure, if mozilla can run remotely. mplayer most likely can't. |
| BenB: | njs: (remember, mozilla is nasty, assumes pixel layout etc) |
| stefans: | nicholas: so each application that requires non-installed kits will raise a flag and ask the user to install a kit from url x.y.z |
| nicholas: | BenB: even MPlayer uses, say, GLX or XVideo which are "extensions" that ship with X. |
| stefans: | nicholas: the rest is up to the user |
| hunger: | * No clientside graphics but the user should be able to install kits for himself. |
| nicholas: | stefans: yep. |
| nicholas: | sold. |
| stefans: | fine |
| njs: | BenB: eh, I'm actually okay with letting clients get at pixel information if they want it. vncviewer is going to want the same thing... |
| BenB: | the question is: can the fresco server have such a complete API and functionality that almost no app will need kits to be installed? |
| stefans: | though I very much like the ability to prototype in python. But that's a different issue, and can be solved differently. |
| nicholas: | the answer is yes, or we haven't done our jobs. |
| BenB: | njs: but it will need lots of bandwidth. I just say I don't know, I surely want mozilal to run remotely. |
| hunger: | Sorry to be hurrying all of you, but I'm getting tired;-) |
| | E0x (~moya@147satb5.codetel.net.do) has joined channel #fresco |
| hunger: | Hi E0x. |
| E0x: | hi hunger |
| njs: | one of the goals I had in mind for my protocol, actually, was to be sufficiently efficient that when push came to shove, remote widgets implemented X-style would actually be possible. Rare and comparatively inefficient, but not dramatically worse than X performance-wise. |
| stefans: | hunger: hmm, ok. We are making good progress, though, no ? |
| hunger: | Clientside widgets that are compositions of existing graphics are no problem... |
| | nicholas is very pleased with what we've accomplished! |
| | hunger is too. |
| stefans: | njs: well, a 'remote widget' could just be a hook into the server holding a little scene graph |
| nicholas: | njs: that'd be wicked, of course! |
| hunger: | Anything about extensibility/flexibility I forgot? |
| BenB: | nicholas: I am not so sure about being so complete. |
| hunger: | BenB: Neither am I... but it seems to work pretty well with X. |
| BenB: | nicholas: what about games, for example? they'll want to have precise control over UI and input. does fresco give that? |
| nicholas: | BenB: well, we're aren't today. in theory that's because we're not finished. in practice... we may never find out... |
| stefans: | hunger: well, we have to get closer to the protocol, and extensibility is an important requirement for it. It's not done yet. |
| nicholas: | BenB: then provide them with an API, in Fresco, that does! |
| BenB: | hunger: X works totally differently, everything is done by the client. |
| hunger: | stefanS_ So bring up the next issue, please. |
| njs: | BenB: that's the kind of edge case that I'm saying should be possible albeit rare. |
| hunger: | BenB: I don't consider games a issue, they tend to not need a GUI like Fresco anyway. |
| stefans: | well, what's the object model that the protocol uses ? Is there any ? |
| oxygene: | BenB: games should run without GUI in the background |
| nicholas: | BenB: GLFresco should be provided, as well as some sort of DirectXish API. |
| | t00R (dopeman@ppp75.txc.net.au) has joined channel #fresco |
| oxygene: | BenB: that needs a separate set of drivers though |
| hunger: | Hi t00R |
| BenB: | hunger: I need to run games on my display server, in a window, that's a must. |
| starseeker: | njs: The only trick with edge cases is to be sure they stay edge. IIRC a complaint of the X guys is that toolkits sometimes did something a stupid way, and that then multiplied to all the clients that used that toolkit |
| BenB: | (for me) |
| stefans: | njs: I didn't read to the end of your proposal. Do you have any clear ideas as to whether and how your protocol would be OO'ish ? |
| oxygene: | BenB: otoh stuff like mplayer is interesting: I'd like to send a theora stream over the wire (preferably the original file) instead of raw images |
| stefans: | BenB: I think a 'tunnel through' graphic (equivalent to 'direct rendering' or 'Canvas' as we call it now) is a must, yes. |
| njs: | GL support is important, but we can't figure out how to do it until we have a driver architecture that can do it, and currently there's no such thing, so... |
| oxygene: | BenB: then it needs a widget like vnc needs, too.. a canvas to pixel-draw on |
| | Signoff: maus- () |
| nicholas: | BenB: if Fresco were in charge of the display--not this Fresco-on-X crap we have now, then it would handle GL in a window just like X does now. |
| njs: | stefans: did you read the 3rd document at all? |
| stefans: | if the server provides a scene graph, how do we talk to that from within the client ? How do we connect a model to its views ? |
| | Signoff: Karina``` ("Leaving") |
| stefans: | njs: I wouldn't call it 'read'. Sorry. |
| njs: | stefans: nod |
| BenB: | oxygene: but with that, we throw out fresco for that game completely, basically. |
| stefans: | njs: I definitely will, though. |
| oxygene: | BenB: yes, the game can't reuse it, anyway |
| BenB: | oxygene: indeed (about theora) |
| BenB: | stefan: what about a movie player? as oxygene said, I don't want to send images over the wire, but the compressed stream. |
| hunger: | stefan: What is the next issue we are going to discuss? |
| oxygene: | even display postscript with JIT is more suitable for multimedia, than a non-extendable (by the app) kit architecture |
| njs: | stefans: the basic model is of "objects" (defined as "an address you can send a message to") scattered across the clients and the server |
| stefans: | njs: ok. What about interfaces ? (type safety) ? |
| njs: | stefans: I ignore that so far :-) (the low level model just worries about shuffling around opaque byte arrays) |
| stefans: | njs: hmm, but it's at that level that extensibility comes into play. |
| njs: | stefans: but that part is reasonably straightforward. You just need to come up with some arbitrary way to encode a method name and its arguments into a byte stream. |
| stefans: | njs: and what about synchronicity ? I agree about what you said with respect to AMI. CORBA developers seem to see that too, now (there is a whole messaging spec) |
| | Signoff: rapha|zZZzz ("Client exiting") |
| cow: | njs, MPI ;) |
| njs: | stefans: There is the possibility that things like multimedia apps might want to just pack raw data into that buffer and use the low-level interface, but I envision coming up with a standard way of marshalling stuff that most objects will use. |
| stefans: | njs: hmm, in CORBA the data-intensive stuff would just bypass the usual protocol. |
| BenB: | stefan: sync: njs' proposal was quite nice about pipelining, that was its stringest point IMHO. |
| BenB: | (but at the same time its weakest - there is only async) |
| njs: | stefans: that's silly, though, and means you have to have multiple connections to juggle, issues with firewalls, it's a mess. |
| oxygene: | BenB: not really.. sync = async+wait |
| njs: | BenB: it's trivial to implement sync on top of async, you just sit around doing nothing until your reply comes back |
| BenB: | oxygene: no |
| BenB: | njs: on which level? I though "async" means that the method returns immediately and .. |
| cow: | BenB, it is. as njs said you just implement some kind of barrier |
| BenB: | I specify a callback for the result. |
| njs: | stefans: my protocol involves maybe ~20-40 bytes of framing information per packet, and then some arbitrary chunk of binary data after that. It's going to be about as efficient at shuffling around data as making an out-of-band connection would be. |
| BenB: | but that's a major pain to use in apps. |
| njs: | BenB: well, yeah, if your apps tried to use CORBA at the level of sending individual IIOP packets, that would be a major pain too :-) |
| BenB: | njs: so, the app interface will be (optionally) sync? |
| BenB: | (optionally for the app to chose, not the API) |
| hunger: | stefan: What is the next issue we are going to discuss? |
| oxygene: | BenB: that could be wrapped away in the idl-generated code |
| | t00R has left channel #fresco because ("Leaving") |
| stefans: | hunger: I dunno. There are lots of things hanging in the air :-) |
| | BenB picks one from the air and eats it |
| stefans: | hunger: for example how to take advantage of existing rendering architectures (I'm thinking of openscenegraph.org) |
| njs: | BenB: ak, no, that one is important! |
| BenB: | lol |
| starseeker: | Can I ask where ggi is at? |
| BenB: | njs: too late, should protect them more. maybe with caps? |
| hunger: | stefan: I was refering to the extensibility/flexibility discussion we are having. |
| stefans: | starseeker: you should ask the GGI people: #ggi |
| starseeker: | stefans: Ah. |
| stefans: | hunger: oh |
| cinap: | starseeker: just swipe it ;) |
| hunger: | stefan: Anything in that area we need to discuss now? |
| | hunger would like to move over to modularity. |
| cinap: | s/starseeker/stefans/ |
| stefans: | hunger: sure |
| mourad: | hunger: I;m still not lear what has been decide wrt flexibility |
| stefans: | cinap: oh well |
| hunger: | mourad: No clientside graphics but user kits basically. |
| hunger: | OK, MODULARITY |
| hunger: | I think we got that right with our kits approach... |
| hunger: | Is that correct? |
| nicholas: | yeah |
| njs: | what does modularity mean, in this context? :-0 |
| mourad: | yep |
| njs: | s/0/)/ |
| stefans: | hunger: yeah, and I think we have to carefully design the protocol for extensibility, too. So it's more than just the ability to install new kits |
| stefans: | njs: I think modularity and extensibility are very similar. |
| hunger: | * Kits are good. |
| oxygene: | "user kits" will result in some generic one (I'd bet: MonoKit) to appear with code upload |
| mourad: | that was easy, wasn't it :) |
| stefans: | njs: modularity means first of all that kits provide domain-specific services |
| hunger: | stefan: Please elaborate. |
| stefans: | njs: but that also implies that each kit adds new stuff the server alone wouldn't know about, which gets us back to extensibility. |
| BenB: | oxygene: which is a very bad idea, if you want to be secure. |
| mourad: | oxygene: Is that bad? I'd think code upload is good in alot of cases? |
| oxygene: | mourad: I see no problem in code upload per se if security is ensured.. that cries for a more domain specific language, though :) |
| stefans: | yeah, I believe uploading code is possible. Of course, that requires some kind of 'virtual machine'. |
| njs: | oxygene: yeah. And a language that you can sandbox in terms of time and memory consumption... |
| stefans: | njs: exactly |
| nicholas: | I know! avaJ. |
| mourad: | phew. I thought that yo guys decided that wouldn't be possible :) |
| njs: | (which is why python and lua and perl and java and ... are all not so useful. Haven't looked at Mono.) |
| stefans: | nicholas: python ? |
| mourad: | C -> bytecode? |
| BenB: | experience has shows that sandboxes do not work for security. |
| oxygene: | mourad: icc? failed ;) |
| nicholas: | stefans: what a mess. Sure, I suppose libpython. |
| oxygene: | BenB: indeed |
| | casi has left channel #fresco because () |
| stefans: | nicholas: mess ? |
| njs: | BenB: sandboxes work great if properly implemented. Bolting them onto a complicated language that wasn't designed for it doesn't work so well. |
| njs: | BenB: but good luck finding holes in E... |
| BenB: | njs: I think java was designed for it, and javascript certainly was, and tons of money went into it, and it still didn't work. |
| nicholas: | stefans: expecting kits to run in untrusted sandboxes. I suppose you could, iff you have a kit in native language, which in turns handles the VM for the bytecoded kits. |
| hunger: | Anyone contributing on the issue of modularity without getting dragged into how secure sandboxes are? |
| njs: | BenB: mm. If Java was designed for it, then they have really stupid API designers. |
| njs: | hunger: :-) |
| nicholas: | hunger: Can I add traversals? |
| cinap: | i think we shouldn't abuse libs as a hight flexibely extension-layer... |
| nicholas: | hunger: May I extend Fresco by adding my own Traversals? (Given that it would break the double dispatch...) |
| BenB: | njs: I thought that applets were there very early in jav's lifetime. |
| stefans: | hunger: heh. Well, I think modularity means that kits provide very specific facilities |
| oxygene: | BenB: java was designed for set-top boxes, not sandboxes in pc network software |
| BenB: | (if not from the start) |
| stefans: | hunger: facilities that not all servers may support. |
| cinap: | libs are dangerous... and have to be installed like a extension for the x-server |
| njs: | BenB: yeah, early in it's public release cycle, but that was sun going "oo, we have this language, let's make it the next big thing on the InterWeb!" |
| mourad: | stefans: and that can call on each other I assume ? |
| hunger: | stefan: What about traversals? |
| stefans: | hunger: so if you can manage to factor out some facility into a kit that basically means that you can run the server without these facilities (i.e. in a stripped down version, say) |
| stefans: | hunger: yes, what about them ? :-) |
| rohara: | how are apps notified about these facilities? |
| | cinap disalikes the java-idea :/ |
| hunger: | stefan: Do we allow for Kits provising them? How did you add davinci's selection traversal? |
| hunger: | rohara: The ask the server wether Kit "whatever" is avaiolable and whether they are allowed to get it. |
| stefans: | hunger: no, davinci doesn't have a special traversal. It's just an ordinary pick traversal. The new thing (which should still be built into the core, mind you) is that this traversal uses a region for picking, not just a point. |
| stefans: | hunger: but why does that worry you ? Even if a kit provides a custom traversal, what would that change ? |
| hunger: | stefan: Can we add traversals somehow? In a Kit or something? |
| nicholas: | stefans: well, a custom traversal will break the double-dispatch on Graphics, won't they? |
| stefans: | hunger: why not ? But do we need new traversals ? |
| hunger: | stefan: I don't remember wether Kits can do that or not;-) |
| stefans: | nicholas: yeah, but I was going to argue to drop the double dispatch anyways :-) |
| rohara: | hunger: are there special policies as to whether an app is allowed to have it? |
| nicholas: | stefans: oh wicked. :) |
| njs: | stefans: oh? tell me about this :-) |
| hunger: | rohara: Courrently not, but there could be. |
| stefans: | nicholas: well, not yet, lets first get CORBA out of the scene graph and then profile. |
| hunger: | rohara: Like Debugger-Graphics are not available to "normal users" or something. |
| stefans: | njs: heh, it's just an ugly trick to avoid all the round trips used for double dispatching. |
| rohara: | hunger: ah |
| njs: | where by "round trip" you mean "vtable call"? |
| stefans: | njs: it's really hitting hard when using CORBA. I have no idea whether it's still a problem without. |
| njs: | stefans: ah, yes. right, vtable calls will be a considerable improvement :-) |
| hunger: | So we all agree that we did the Kits mechanism right? Anything else to add about modularity? |
| stefans: | njs: but Fresco98 had a little enum discriminator. It obviously looks a bit ugly, but it's more efficient. |
| njs: | (about 500 times faster, I think?) |
| stefans: | njs: it's a double vtable call ! |
| njs: | stefans: yeah |
| stefans: | hunger: well, what about the console API ? |
| hunger: | * Kits are a good mechanism for modularity. We did that right. |
| stefans: | hunger: that's where part of our extensibility sits, too. |
| hunger: | stefan: Good point. |
| hunger: | stefan: So far I found the current console API OK. |
| stefans: | hunger: I started to work on that API mainly because there wasn't any single console to choose, GGI was 'the best' but its future was/is unsure, SDL is limitted, etc., etc. |
| hunger: | nicholas: Any improvements we need wrt. the console? |
| hunger: | stefan: I think that API wioll evolve as we add new targets in the future. |
| hunger: | stefan: Currently I can't think of something to add. |
| stefans: | hunger, nicholas: I reiterate, I'd like to look at openscenegraph (or the likes). They do wonderful stuff, and I'd like to think about whether we could use that. |
| cinap: | hunger: svg ;) fun |
| stefans: | or move on to openGL 2.0 once that gets available. Etc..... |
| njs: | Or if Fitz ever gets anywhere, that might be interesting. |
| stefans: | yeah |
| stefans: | that touches the imaging model. Our DrawingKit is quite limitted right now. How can / will it evolve ? |
| cinap: | what/who is "Fritz"? |
| cow: | hunger, i'm having trouble to find how to dieplay a cursor in e.g. textinput. But i may not have looked at the correct part yet.. Can't say anything else to the console atm. |
| hunger: | cinap: A 2D vector lib, the successor of libart. |
| stefans: | cinap: "Fitz", not "Fritz" :=_ |
| cinap: | >_< |
| | cinap is tired too |
| rohara: | what about the extension mechanism that the consoles have? |
| cinap: | thx hunger |
| cinap: | :) |
| hunger: | _cow: That shouldn't be a console issue. |
| stefans: | rohara: I think that's fine. It works, at least. And it's less of an issue as it isn't exposed to the client. |
| cow: | hunger, i suppose so. i'll remind you on showing me a cursor later |
| nicholas: | hunger: nope. |
| rohara: | stefans: ok |
| nicholas: | hunger: well wait. |
| hunger: | stefan: Of course the DK will evolve. That's not really client visible, so I don't consider that a mayor issue right now. |
| stefans: | hunger: oh, you are right :-) |
| nicholas: | hunger: SDLGL versus GLDrawingKit is a little issue with the mouse pointer. |
| hunger: | stefan: In fact maybe we should consider not to call the DK a Kit at all... |
| | stefans forgot that the scene graph is now local. Hurray ! :-) |
| hunger: | stefan: Actually that doesen't need to have a CORBA interface at all with a local SG. |
| nicholas: | hunger: at the moment, the two do need to cooperate in ways that I don't want to restrict future GLDK development. |
| stefans: | hunger: hmm, dunno. However we call it, it's an extensible module (DK <-> DK3D) |
| njs: | stefans: yeah, a local scene graph makes a lot of stuff easier |
| njs: | stefans: :-) |
| hunger: | nicholas: Right... but I'd love to change the mechanism of the GLDK anyway (to be display-list based). We should discuss that sometime. Problem is that I can't find a GL wrapper with the functionality needed for that. |
| stefans: | one of the things I'd like to look into (if I had a second life) would be how to integrate GUI-related scene graph nodes ('Controllers', say) into something like OSG (openscenegraph). See how difficult that would be, etc. |
| hunger: | stefan: I'd like to not get into to deaply into the DK discussion right now. |
| stefans: | hunger: understood |
| BenB: | stefan: you mention OSG a lot, you need to tell me more about what you like about it :). |
| BenB: | stefan: are you familar with Open Inventor? |
| BenB: | (just curious) |
| stefans: | hunger: I'm just trying to point out that the imaging model and the whole 'what is the scene graph API' thing is now up to redesign (now that we don't impose CORBA on it any more). |
| hunger: | OK, I still have "USEABILITY/CONSISTENCY", "SEMANTIC ABSTRACTION" and "LANGUAGE TRANSPARANCY" on my initial brainstorming list. |
| stefans: | BenB: yes. We use OSG at work. Its kinda the successor of OpenInventor. The same people working on it, anyways. |
| cinap: | BenB: http://c2.com/cgi/wiki?OpenSceneGraphFaq |
| hunger: | Let's start with "LANGUAGE TRANSPARENCY" |
| stefans: | hunger: ok, fine. Let's move on |
| BenB: | stefan: oh, didn't know that it's the same persons. |
| njs: | I think one of the more subtle, but also most important, results of getting rid of CORBA in the SG will be that it will be much easier to change things in the future |
| njs: | So getting the design "just right" ahead of time becomes less important |
| hunger: | I think we need C++ and python. Perl, Java and rouby are nice to have to me. |
| stefans: | njs: yes. But that only displaces the problem. |
| oxygene: | hunger: languages will come as demand exists.. |
| stefans: | njs: we still have to define some 'interfaces' client and server agree upon. |
| oxygene: | hunger: so c++ and python for now, it seems |
| njs: | well, but it allows incremental improvement, and trying experimental stuff, letting the code lead the design, etc. |
| | stefans votes +1 for both, c++ and python :-) |
| stefans: | yes |
| hunger: | oxygene: Sure. I'm talking of what we absolutely need now (plus some more important languages) |
| BenB: | hunger: of course, I argue Java is a must :) |
| njs: | in the short term, I think C++ and Python are important; in the long run, of course, we need to support "everything". |
| rohara: | LISP |
| | stefans would sign that |
| hunger: | * Python and C++ are a must. |
| nicholas: | we need to allow for support for "everything". that doesn't mean we have to support everything. |
| mourad: | if the protocol is simple enough bindings shouldn't be a problem, right? |
| hunger: | * Other languages (everyone) can come later. |
| oxygene: | hunger: IDL is a must |
| njs: | i.e., I will put time into Python and C++, and if anyone else wants to make other languages work, good for them :-) |
| hunger: | * Some form of IDL is a must. |
| stefans: | do we agree that the basic model is still the same as in CORBA: language-independent wire protocol with language specific runtime environments (replacing the 'ORB') ? |
| stefans: | hunger: yeah |
| hunger: | Can we all agree on these three points? |
| starseeker: | rohara: Go lisp :-) |
| hunger: | * language-independent wire protocol with language specific runtime environments |
| BenB: | njs: sorry to be blunt, so you'll break java support? |
| stefans: | hunger: and depending on what kind of object model we agree on, we may even want to use CORBA IDL for it. |
| oxygene: | hunger: the second one isn't necessary |
| njs: | BenB: I won't worry about it. If you want to make it work, go for it. |
| stefans: | hunger: I'm just saying that I wouldn't rule that possibility out at this point. It's hard to come up with consistent languages. |
| stefans: | of course, unicode is a must, too. |
| BenB: | njs: well, I probably wouldn't want to write a new mapping. |
| hunger: | stefan: I'm not ruling out anything at this point, just listing requirements. |
| stefans: | hunger: fine :-) |
| hunger: | Any more wishes wrt. language transparency? |
| stefans: | hunger: is 'language transparency' settled by this ? |
| rohara: | well could we say what would rule out a language ? |
| stefans: | rohara: sure: missing manpower to implement the mapping :-) |
| rohara: | stefans: ok fine with me |
| hunger: | Can we move on to "CONSITENCY/USEBILITY" then? |
| stefans: | sure |
| hunger: | Not much to say about that at this point... |
| stefans: | I agree. I think we got that one right :-) |
| hunger: | We can have consistency through the kits... |
| BenB: | yeah |
| hunger: | usebility is something we need to keep an eye on as we go. |
| stefans: | hunger: well, the main point remains 'do it server-side'. |
| BenB: | stefans: in fact, that's all I was saying :) |
| mourad: | Just a remark, two competing kits on thesame level with different api's will still make things inconsistent |
| nicholas: | mourad: if the user choses to do that, then we won't stop them. |
| stefans: | mourad: oh, you can be inconsistent if you wish. |
| njs: | mourad: Don't Do That Then |
| oxygene: | mourad: like toolkits today, yes.. because of this the APIs must be good enough that people see no need for NIH |
| mourad: | just saying, that putting things in the server doesn't guarantee consistency |
| mourad: | what oxygene says |
| nicholas: | oh. right. |
| oxygene: | hmm.. versioning in the API? |
| stefans: | hmm, that brings up a little paranthesis: interface versioning. Not important tonight, though |
| hunger: | * we encourage consistency with our Kits approach |
| mourad: | heh :) |
| hunger: | * We should focus on useability as we go |
| nicholas: | interface versioning? yes. I don't ever care how you implement it. |
| hunger: | Is that OK with everyone? |
| nicholas: | s/ever/even/ |
| BenB: | hunger: yes |
| stefans: | (imagine we have a widgetkit API, and someone finds it incomplete, i.e. wants to evolve it, so it becomes 'WidgetKit 1.1'. What about compatibility ? Etc... |
| cinap: | jup |
| nicholas: | hunger: usability s/p |
| mourad: | sounds good |
| oxygene: | hunger: * investigate how interface versioning can be done |
| hunger: | oxygene: OK, let's add that: |
| hunger: | * investigate interface versioning. |
| hunger: | Even though that should be easily added as a property of the kit. |
| stefans: | hunger: actually, that's a bit of an extensibility issue, too. |
| stefans: | hunger: extensibility and consistency. If we don't get versioning right, interfaces will proliferate, which we do want to avoid, right ? :-) |
| hunger: | stefan: Good that we brought it up here then instead of forgetting about it, isen't it ;-) |
| stefans: | hunger: no, it's not as simple as adding a property. |
| hunger: | stefan: Why not? |
| stefans: | hunger: in fact, this kind of extensibility has to be built into the protocol, if we really want to support it. |
| BenB: | stefans: Dublin Core? ;-P |
| stefans: | BenB: er, that's just the property part. What about (binary) compatibility between interfaces ? |
| BenB: | stefans: yeah, got you. |
| | hunger is tiered and even more stupid than usually. |
| stefans: | ok, 's really just a paranthesis. |
| BenB: | stefans: I am still assuming (and hoping for) CORBA as the client/server protocol |
| stefans: | BenB: we'll find out ;-) |
| BenB: | hunger: same here. |
| hunger: | Can we open the ring for "SEMANTIC ABSTRACTION" then? |
| stefans: | BenB: though versioning is something CORBA did not get right :-) |
| stefans: | hunger: yes, sure |
| BenB: | maybe move the CORBA showdown to another day? |
| BenB: | stefans: heh. |
| stefans: | BenB: I thought that was one the reasons so many people showed up tonight :-) |
| njs: | hmm, the CORBA showdown seems to be one of the more important things to talk about? |
| mourad: | BenB: stop teasing :) |
| BenB: | stefans: great, then they'll all come another day as well ;-P |
| stefans: | ok, semantic abstraction |
| stefans: | hunger: what about it ? |
| mourad: | well, we went over it earlier no? |
| nicholas: | where's scanline? |
| hunger: | Hey, you were firing things at each other about this earlier tonight... |
| stefans: | hunger: supporting multiple abstraction levels when requesting GUIs from the server |
| njs: | nicholas: bored with GUIs :-) |
| hunger: | Why is everyone suddenly so quiet when we get to it officially? ;-) |
| nicholas: | njs: oh? did he drop picogui? |
| stefans: | hunger: :) |
| njs: | nicholas: more or less. |
| stefans: | hunger: to me 'semantic abstraction' means to be able to require any GUI entity that is able to handle a given task (that's the tasket idea indeed). |
| cow: | hunger, so instead of building up a scrollable box for DKblah, request flexible_hbox from wherever. fine and would be really nice to have |
| mourad: | Apps should use as high as abstraction as possible, and use lower levels when needed |
| stefans: | hunger: does it mean something else to others ? |
| hunger: | Is this "multiple abstraction levels" all? |
| hunger: | stefan: Dunno. I was with your idea since you explained it to me at the linuxtag;-) |
| mourad: | The question becomes: how high an abstraction do we provide out of the box (since apss need to depend on it)? |
| hunger: | stefan: So I don't know what others came to understand of it. |
| njs: | which exact kits we provide isn't really a foundational issue; we can always quibble about the details later. Sure, I think building higher and higher abstraction layers until we get stuck makes sense. |
| mourad: | will that alone allow is to do what scanline meant? |
| oxygene: | hmm.. so we get a libBabel soon? |
| njs: | Probably not the first priority, though; clients can always get along with the lower level stuff (analogous to what current APIs provide) until we figure out how to make taskets work. |
| stefans: | njs: well, yeah, but it draws on the 'composition' paradigm. |
| BenB: | stefans: abstraction I meant more genernally. X doesn't even know a checkbox, fresco does. |
| BenB: | stefans: i.e. abstraction on several levels. |
| stefans: | njs: so composition as one of our main foundations is a requirement for this to work. |
| njs: | mourad: I personally don't think what scanline meant was coherent, so I'd say no, but... |
| hunger: | So all there is: * We will provide access to Fresco's functionality at different abstraction levels? |
| nicholas: | hunger: I don't think that's quite it. |
| nicholas: | hunger: suppose my application is a simple document model application. |
| njs: | stefans: yes, but providing pre-composed widgets is still just a tiny part of what makes composition good ;-) |
| hunger: | nicholas: Neither do I. But I never thought much about that:-) |
| nicholas: | hunger: Fresco should allow me to adapt from a PDA which has no notion of a filesystem, to a full desktop, or even Konqueror style source URLs (I forget what they're called). |
| hunger: | nicholas: kioslaves IIRC. |
| stefans: | njs: yeah |
| nicholas: | hunger: so "document interface" means to a Palm, that I have no notion of open or save, even. Fresco should assist my program in adapting to that environment as best as possible. (Not that it should do the work for me, btw.) |
| nicholas: | hunger: kioslaves. thanks. |
| njs: | nicholas: that sounds nice, but it also sounds like you might be defining Fresco's scope to be so huge that it can never work. |
| nicholas: | njs: that's valid critism. |
| njs: | nicholas: I'd rather focus on things we can do now, that will later give us a foundation to figure out things like that. |
| hunger: | njs: Sounds like Moscow to me;-) |
| stefans: | nicholas: yeah, very good point. In fact, you are really stretching it a bit, as that's getting into the model domain. Quite tasty... |
| njs: | oh, right, Moscow! I'd forgotten about Moscow :-) |
| nicholas: | Sounds like Document Architecture to me. |
| BenB: | yes, I also think that taskets are nothing to be worried about right now. |
| BenB: | I don't think they can do what you want them to do anyways, allowing apps to run from cellphones to 3D. |
| hunger: | njs: Everybody has... everybody but us long time lurkers;-) |
| stefans: | nicholas: hmm, Document architecture first of all means dynamic data exchange, graphical embedding, etc. |
| nicholas: | stefans: oh really?? wow! i had it wrong!! |
| stefans: | nicholas: the latter we already touched, the first is something fresco only needs to care a little about. |
| cinap: | good night... |
| stefans: | nicholas: i.e. provide some basic protocol to let applications negotiate the details for the exchange |
| mourad: | cinap: bye |
| hunger: | cinap: Good night. |
| nicholas: | cinap: sleep tight! |
| cinap: | i have to sleep... my company will shot me |
| cinap: | >_< |
| cinap: | thx |
| cinap: | n8 mourad, hunger, nicholas |
| njs: | cinap: see you |
| cinap: | n8 njs |
| oxygene: | shooting you won't give them a motivated employee... |
| | Signoff: cinap ("close the world, txEn eht nepo") |
| stefans: | nicholas: your idea sounds very interesting though, but a bit out-of-scope at this point, I agree. |
| nicholas: | stefans: mhmm... that's a complex issue. |
| BenB: | stefans: it's very relevant to the communication protocol. |
| hunger: | Could someone else please formulate this consensus item please. |
| nicholas: | stefans: it doesn't really require more than a proper "programming guidelines" document, frankly. |
| stefans: | nicholas: well, I'm not sure. If we provide some basic streaming protocol... |
| njs: | "We'll worry about high level semantic interfaces later"? |
| stefans: | :) |
| nicholas: | We'll worry about high level semantic interfaces forever? |
| mourad: | or more diplomatically: |
| BenB: | heh |
| stefans: | haha |
| mourad: | * we leave the option open for high level semanic interfaces |
| BenB: | nicholas: I actually plan to get to OOUI within my lifetime :) |
| njs: | stefans: oo, oo, I know a protocol that provides a bare-bones way for clients to interchange data and otherwise stays out of the way! ;-) |
| hunger: | BenB: We are lucky that you are still young then;-) |
| BenB: | hunger: I am? I just turned 26! :( |
| stefans: | nicholas: well, 'Document centered architecture' is about data exchange, i.e. have one application hand over some of its models to a different applet to edit / view it. |
| nicholas: | njs: if you're gonna say HTTP then I'm gonna slap you. ;-) |
| mourad: | BenB: hey, me too :) |
| hunger: | BenB: So what... I'm turning 30 this year. |
| nicholas: | stefans: ok. then I used bad terminology. |
| njs: | nicholas: ewwww |
| stefans: | nicholas: so the question is how much support fresco needs to provide for this to be possible. Implement the whole serialization ? Just the negotiation ? |
| nicholas: | stefans: Good question, and far out of my league. :) |
| stefans: | nicholas: ok, so 'let's come to this back later' |
| nicholas: | 26? and I'm haven't turned 20 yet! |
| | Signoff: ms_ ("Client Exiting") |
| mourad: | 26 isn't that different from 20, really :) |
| hunger: | Do we need to discuss this at the requirements stage? |
| stefans: | nicholas: we just have to keep it in mind because a DCA is one of the central goals |
| nicholas: | stefans: agreed. |
| stefans: | mourad: as is 35 ;-) |
| BenB: | hunger: yes. requirement: I want to stay 25. |
| mourad: | :) |
| mourad: | okay. Next? |
| stefans: | ok. Well, I a guess we could come up with lots of more issues if we really thought hard enough. |
| njs: | okay, so now that we've successfully ignored^H^H^H^H^H^Hgone over semantic abstraction, what's next? |
| hunger: | Consensus item: * Fresco will offer access to its funcionality at different abstraction levels. * Coumpund ducument architecture is in scope of this project? |
| nicholas: | lol |
| stefans: | should we stop collecting requirements for now ? |
| stefans: | I mean, one important question is "what now ?" |
| njs: | hunger: I don't agree with the second of those as phrased |
| stefans: | will people just randomly pick issues and work on them, i.e. suggest new designs ? |
| njs: | hunger: perhaps "allowing the creation of a..." |
| hunger: | njs: How would you put it? |
| hunger: | * Fresco will offer access to its funcionality at different abstraction levels. |
| hunger: | That one was undisputet;-) |
| nicholas: | sure. |
| stefans: | njs: I'd like DCA to be 'in scope', but from a practical point of view I have to agree with you. |
| njs: | I'm not convinced that there's anything in such an architecture that has to go into Fresco proper, or that putting such things into Fresco proper is a good use of resources |
| hunger: | * Fresco will allow for the creation of a DCA |
| mourad: | well, I agree with trying to keep things simple for now, and not blocking any future avenues if possible... |
| stefans: | well, graphical embedding doesn't make much sense without some form of model / application collaboration |
| stefans: | so in order to explain why we want graphical embedding, we have to suggest some use case |
| hunger: | OK. That was everything on my brainstorming list. |
| stefans: | (which DCA provides) |
| njs: | I'd rather start with modest goals and then run out than start with huge goals and never reach them, yeah :-) |
| hunger: | Would you mind continuing this meeting at another time? |
| njs: | stefans: not really, graphical embedding is plenty useful within an app. Think openoffice, or presentation software, or... |
| stefans: | (DCA='document centered architecture'; CDA='compound document architecture'...they are really just synonyms) |
| hunger: | Maybe same time tomorrow? |
| stefans: | hmm, if you want. |
| mourad: | is anyone else logging, by the way? |
| nicholas: | mm, I might be late. |
| njs: | I have logs, though xchat's logs aren't the bestest. |
| stefans: | I agree that we have collected quite a list of issues. |
| hunger: | I am very tired and do want to participate in the CORBA discussion... |
| stefans: | nobody answered my question though: what are we going to do with it ? |
| hunger: | stefan: And you have some time to reread Nathaniels papers. |
| stefans: | hunger: heh, thanks :-) |
| nicholas: | stefans: it? |
| stefans: | nicholas: it==the list of issues we just collected |
| hunger: | stefan: I'll write up a list of requirements we collected today... |
| njs: | stefans: rewrite Fresco? ;-) |
| stefans: | nicholas: read: should we try to fix some goals ? |
| mourad: | adopting a bit of "worse is better" would be good |
| nicholas: | stefans: someone should make minutes of what we've done. |
| stefans: | njs: good idea ;-) |
| nicholas: | stefans: then we should tear it apart on the ML. |
| hunger: | stefan: And tomorrow we can talk over how those reflect on the architecture we have, what needs to get changed, etc. |
| stefans: | hunger: hmm, I'll be two hours late tomorrow (compared to today) |
| njs: | and maybe get into the actual CORBA discussion, whose outcome I am very curious about, as you might imagine :-) |
| stefans: | hunger: or during the day. |
| njs: | stefans: erk. That's 2:00am for the Germans... |
| stefans: | njs: oh ? Now I'm surprised ! :-) |
| hunger: | njs: 3am... |
| mourad: | it's 3am here |
| njs: | hunger: but <todays meeting start time> + 2 hours is 2am, no? |
| hunger: | njs: That's why I don't want to start another discussion right now... ewspecially when I am very interessted in its outcome. |
| hunger: | njs: We have been going on for 3h not 2. |
| hunger: | stefan: How about the day after tomorrow? |
| njs: | hunger: yes, but stefan said if we do it again tomorrow he can't make it until 2 hours later? |
| mourad: | well, quick poll? kick corba or not? ;-) |
| nicholas: | hunger: the +2hrs was stefan being late 2 hrs. |
| stefans: | nicholas: seriously: do you think we could divide the issues such that everybody who has some spare cycles (and of course motivation) has some part to work on, towards more concrete suggestions ? |
| hunger: | stefan: I definitly don't want to start later than today. |
| stefans: | hunger: nope, I'm busy wednesday evening |
| nicholas: | stefans: only with the guidance of solid requirements analysis, yes. |
| hunger: | stefan: rehersals? |
| nicholas: | thursday? |
| stefans: | hunger: yep :-) |
| stefans: | nicholas: another rehearsal :-) |
| njs: | stefans: does earlier work? |
| nicholas: | doh. |
| hunger: | How about next monday? |
| nicholas: | friday? |
| nicholas: | ok, next monday. |
| njs: | stefans: (tomorrow, I mean) |
| hunger: | Or during the day for stefan... |
| hunger: | stefan: when would that be? |
| stefans: | fine with me. But still, two hours later, sorry. Before I'm with my family. |
| hunger: | stefan: 4h earleir then this meeting started? |
| nicholas: | mm, my schedule has school up until 1 hr before the meeting would start tommorow. |
| nicholas: | hunger: I can't make it. |
| stefans: | hunger: I can't tell (for 'during the day', as I'm very busy at work these days) |
| | njs sighs |
| nicholas: | set it for +1week? |
| stefans: | I don't really have an opinion about CORBA right now. To much free parameters to fix... |
| | Signoff: cinap_lenrek (Ping timeout: 14400 seconds) |
| stefans: | I'm easy. Of course, if we don't have to define the protocol and implement it, all the better... |
| stefans: | For me the CORBA discussion could go on by email. At least I'm not in a position where I can contribute via chat. I have to think more about the arguments people bring up. |
| njs: | nod |
| nicholas: | I'd need a chance to read njs' material. |
| njs: | IRC is useful for hashing out problems, but not so much if people haven't had a chance to think about the issues first... |
| mourad: | yea me too... njs' points are tough to disagree with though (and why would you want to) |
| njs: | (sorry about sending those off so late) |
| stefans: | I'd suggest we all read over the logs from tonight (njs: do you still have your irc log beautifier ?), someone should write minutes and mail them to the list, so we can see how the reaction is there. |
| njs: | stefans: was never my irc log beautifier, but I think it's in the web module. |
| stefans: | njs: ah, fine. |
| | hunger_ (~hunger@pD9E64843.dip.t-dialin.net) has joined channel #fresco |
| njs: | stefans: and it may be specific to the log output of some particular IRC client, I forget |
| hunger_: | Did I miss something? |
| njs: | hunger_: I'll pm |
| stefans: | hunger_: we just decided to keep using CORBA |
| hunger_: | Last thing I heared was that stefan said he can't tell... |
| njs: | hunger_: we just decided to throw out CORBA entirely |
| njs: | stefans: hey! don't lie to the man! that's not nice! |
| | Signoff: BenB (No route to host) |
| stefans: | who, me ? |
| rohara: | we just decided to cut CORBA in half and find out the real mother. |
| oxygene: | heh |
| mourad: | You think development will be easier if we throw out corba, btw? |
| hunger_: | So we will discuss on the list? |
| stefans: | who did log ? Who could beautify it and put it to the other logs ? Who could write the minutes ? |
| hunger_: | stefan: I'll write up something to the list tomorrow. |
| mourad: | no log here |
| stefans: | hunger_: well, I hope it will go well. Discussions as broad as that tend to get out of focus via email. |
| | njs has xchat logs, if anyone wants them, but can probably put his limited time to better use on things besides writing up minutes |
| stefans: | hunger_: in the worst case we have to come back here :-) |
| hunger_: | stefan: OK, so we will try via mail. |