| | Value of LOG set to ON |
| | graydon is logging now.. |
| Jordy: | *** Starting logfile IrcLog |
| Jordy: | oh, damnit |
| Jordy: | i guess i can turn mine off |
| graydon: | multiple logs is fine |
| crashcut: | ok... i'll mail the log to graydon tomorrow (MET) |
| graydon: | I have to go in 5 minutes anyway.l |
| crashcut: | have to clean up some msg things ;) |
| graydon: | crash: thanks. |
| crashcut: | bye =) |
| | Signoff: crashcut (relay) |
| | graydon ponders this |
| graydon: | I think.. |
| Jordy: | graydon: well like i said, i can do the same basic thing with regex |
| Jordy: | the problem is what stefan was talking about |
| Jordy: | storing things like *fonts*bold = blah |
| Jordy: | and then storing fonts.arial.bold = otherblah |
| graydon: | Jordy: matching amongst a consistent set of patterns is actually the inverse of what you're visualizing |
| Jordy: | and having it actually work correctly :) |
| graydon: | Jordy: you're thinking the registrar DB will hold a tree of some sort |
| Jordy: | yeah, that's what i'm thinking :) |
| Jordy: | what are you thinking |
| graydon: | Jordy: ideally, it should hold a set of objects, each of which matches itself only against those paths in the scene graph which its pattern matches |
| Jordy: | define scene graph... |
| graydon: | Jordy: the DAG of graphics on the screen, or of XML nodes in a document |
| Jordy: | actually, never mind i understand |
| Jordy: | doesn't LDAP implement something similar to what you want, it's pattern matching looks different than XSL, but it's functionally the same |
| graydon: | Jordy: i.e. registrar could hold something like "*font=helvetica" and that doesn't have any meaningful position in a tree. rather, it matches against a tree that the application using the registrar provides |
| graydon: | Jordy: no, LDAP is a tree-structured storage model |
| Jordy: | damn, i need to stop thinking in trees, haha, it's just the logical way to organize data :) |
| graydon: | Jordy: in this view, registrar becomes a sort of "tree interpreter". Like a regex matcher, only the thing it's matching on isn't its own data, it's chunks of the scene graph. |
| Jordy: | hmmm |
| graydon: | Jordy: it's own data is a set of rules which get sorted, prioritized and optimized so as it can interpret a tree context rapidly and provide the user with the appropriate matching keys. |
| Jordy: | alright, well then what will store the actual data? :) |
| graydon: | Jordy: for instance, in the example there, I've stored "*font=helvetica" in registrar. Now I pass registrar a path to /mozilla/dialog/textWidget/font. Registrar should (unless something overrides the first rule) return "helvetica" |
| Jordy: | not the patterns that the data is to matched against |
| Jordy: | oh ok, registrar is to handle ptterns and data |
| graydon: | Jordy: registrar will have to keep the values as well as the patterns. |
| graydon: | yes |
| Jordy: | the more general the pattern, the lower it's priority correct? |
| graydon: | heh.. I'm noticing this is really supremely weirder than the windows registry. |
| Jordy: | yeah that's what i'm thinking :) |
| graydon: | Jordy: well, I'm hoping the prioritization and resolution semantics in the XSL "pattern matching" section are sane and we can just use them. |
| stefan: | Graydon: at least it's much more powerful :-) |
| Jordy: | windows registry is simply a data/value storage facility, there are no pattern matching routines... the application itself deals with patterns |
| graydon: | stefan: hell yeah. I'm wondering if it can be made at all efficient. I mean, usually when you read a style sheet, you compile it into a form in memory which is almost directly executable. |
| | Signoff: al (xchat exiting..) |
| Jordy: | i'm thinking the same thing, how are you going to continually parse this sorta thing to make it run with any real speed |
| graydon: | stefan: in this case, the whole registrar would have to be "recompiled" when you add new rules which alter the resolution priorities |
| graydon: | Jordy: well, I think it might not be too bad |
| Jordy: | basically, i could use a splay tree to optimize it |
| graydon: | Jordy: cause there's 2 really major uses |
| graydon: | Jordy: the statc (literal) patterns can be matched swiftly in a hashtable or btree. |
| graydon: | Jordy: and those are the ones, I think, which will change most often |
| stefan: | Graydon: the data base is a subject which notifies all observers about changes. Beside that, I don't see any need to reparse it 20 times per second... |
| graydon: | Jordy: the complex matching patterns, I suspect, will change less often. and there'll be fewer |
| graydon: | stefan: no, not to reparse 20 times a second; but if I add a new rule, internally I might need to shuffle around how I am representing the rules |
| graydon: | stefan: if I represent them as some sort of sorted matching engine |
| Jordy: | so you want me basically to store X style resource configurations in the registrar and do all the pattern matching internally |
| Jordy: | hmmm |
| graydon: | Jordy: that'd certainly be groovy. again, I'm not sure if it's remotely efficient. |
| Jordy: | so when an application rquests "/titlebar/font" and *font=helvitica, i'd return helvitica |
| graydon: | I'd like to think some more on this, and maybe talk to some stylesheet gurus I might happen to know :), but I have to go now. |
| Jordy: | or something :0 |
| graydon: | Jordy: yeah |
| Jordy: | i guess i should research X resource configs |
| stefan: | Jordy: look into the Xlib implementation |
| graydon: | Jordy: see if you can grok the specification of the XSL pattern language too, as it's worth $90,000 :) |
| Jordy: | man, I have an incredibly hard time reading Xlib :) |
| stefan: | Graydon: fine. then let's stop here. I feel the most urgent has been said. |
| Jordy: | alright, i get it... i'm going to read the fresco manual |
| Jordy: | then i'll go readup on resource configs and how applications request settings |
| Jordy: | then i'll figure something out :) |
| stefan: | Jordy: read the StyleValue/Context/Implementation etc. sources too, but be warned, it's more difficult to read than Xlib :-) |
| graydon: | Jordy: cool. read the tutorial actually. it's quite helpful. If you have questions do it in public on the ML and we can maybe get some confusion resolved. I suspect the "offsets" will throw you off. At least, I was confused :) |
| graydon: | ok, I"m closing trhe log |
| Jordy: | no problem |
| | Unknown command: LOG |
| Jordy: | i'm going to head out |