<plasticmillion> ok, and hi Hannibal :-)
<NeilAway> Hannibal: it's a general knowledge show, not multiple choice
* plasticmillion wonders if Hannibal is still speaking to him
<Hannibal> I am, but I'm also busy
<Hannibal> hang on for a bit :)
<NeilAway> plasticmillion: I assume mentioning the World Cup would not be a good idea ;-)
<plasticmillion> yeah, boo Italy!
<plasticmillion> Hannibal: no stress, just saying hi :-)
<NeilAway> Hannibal: the question was along the lines of, "which country's word for the @ sign translates literally as monkey ball" but I might have misremembered
<NeilAway> plasticmillion: no, I don't know how widgets relate to popups, sorry
<plasticmillion> NeilAway: no worries, I got it to work but was curious about whether I missed a simpler approach
<plasticmillion> probably not...
<Hannibal> NeilAway: myth.
<Hannibal> seriously, monkey tail... it has nothing to do with balls. At least, not in Dutch.
<NeilAway> Hannibal: I'll see if anyone erased it yet, if not, I could double-check
* mmc (mmc@moz-C81D45CC.maths.ed.ac.uk) has joined #developers
* basanta (basanta@F139D31E.D2AF11BA.15028B5A.IP) Quit (Client exited)
<Hannibal> plasticmillion: so, I have problems with a lot of your suggestions. Unfortunately.
* einpoklum (someone@moz-DB87634F.dynamic.barak-online.net) has left #developers
<Hannibal> for one, I'm wondering why you still didn't post to dev.platform :P
* DaaWk (daa@D1269F99.2FD6AAB3.CD6AC7F.IP) Quit (Ping timeout)
* DaaWk (daa@D1269F99.2FD6AAB3.CD6AC7F.IP) has joined #developers
<Hannibal> you mentioned you don't want to have the service do message catching. As this is supposed to be a replacement for the current nsIConsoleService, it'll have to do that, on branch at least, since we can't change interfaces.
<Hannibal> the filtering could just as well be done by clients themselves, as there *is* a category attribute
<Hannibal> I really don't want to try and add symbols/variable-value stuff to the current spec because then I'd be 100% sure I wouldn't finish it.
<plasticmillion> Hannibal: I can post all that to dev.platform but I wanted to run it by you first
<plasticmillion> I noticed the category.. that's fine
<plasticmillion> it's a convenience to have the filtering done but the service... as I said, very similar to what the observer service does
<Hannibal> and we need to have the logLocalizedMessage and logRawMessage thing there because otherwise we're (a) not doing what bz said, and (b) adding more interfaces where 1 would do perfectly well. The point is that the callers should not be depending on localization, IIRC.
<Hannibal> at least, that's what bz said
<Hannibal> and I agree with that
<plasticmillion> also bound to be far more efficient since the service itself can organize listeners by category (in a hashtable?) instead of doing a million string compares
<Hannibal> and seeing as this interface is in c++
<Hannibal> and in xpcom/io
<Hannibal> I don't really see how we'd do anything with js at that level.
<Hannibal> that'd also be miles slower than what we currently have.
<plasticmillion> ok wait a sec, slow down
<plasticmillion> first of all the symbol/variable stuff
<plasticmillion> actually first of all the message caching
<plasticmillion> what do you mean "we can't change interfaces"?
<plasticmillion> isn't that exactly what you're doing?
<Hannibal> but I'm keeping existing functionality and doing any changing in a way that keeps the current functionality
<Hannibal> what you're proposing wouldn't do that.
<Hannibal> ie, we can't throw away the message caching functionality
<Hannibal> as that'd break backwards compat.
<plasticmillion> why can't the misnamed "JS console" window cache the messages?
<Hannibal> you miss the point
<plasticmillion> apparently
<Hannibal> extension authors and the like can also use the interface
<Hannibal> so what we can do is irrelevant
<Hannibal> no matter how much we'd like it not to be.
<Hannibal> we just can't screw the people not in our code using the interface over that way.
<Hannibal> sorry for the grammar in that sentence :s
<plasticmillion> well people would have to update their extensions, wouldn't they
<plasticmillion> the interface is renamed, totally different, etc.
<Hannibal> that's exactly what we can't do. And we're supposed to keep the current interface, actually
* spasmFace (Miranda@moz-2F5C9CCF.dyn.iinet.net.au) Quit (Ping timeout)
<plasticmillion> so there would be two interfaces for the console/logging service on the branch?
<timeless> hannibal: note that you're allowed to add interfaces on branches
<timeless> plasticmillion: that's legal
<Hannibal> timeless: and that's what I'm doing.
<plasticmillion> no that's fine
<Hannibal> apparently.
<plasticmillion> I'm just trying to figure out a way so the new stuff doesn't have to be totally wrong and broken just to keep compatibility with the old stuff
<Hannibal> plasticmillion: but seeing as the new interface would have nsIConsoleService as its parent for compat with the current code
<Hannibal> we can't just ditch the functionality that the console service currently does
<Hannibal> hrm
<Hannibal> or maybe I'm confused right now.
* Hannibal goes to actually open the idl files again
<plasticmillion> I'm passionate about this because, unfortunately, if the service caches all messages then it's totally useless to us
<plasticmillion> how can you pump through a large volume of messages in that case?
<plasticmillion> let me think about this for a sec
<Hannibal> plasticmillion: I suggest you look at the js console
<Hannibal> that currently hacks around that if you hit the clear console button
<plasticmillion> go on...
<Hannibal> so I don't see why you shouldn't be able to use similar hacks.
* Pike just sees branch and localized messages and wonders why folks are talking about that
<Hannibal> Pike: that method would either not be there on branch or return NS_ERROR_NOT_IMPLEMENTED.
* Hannibal mutters.
<Hannibal> I don't suppose shaver is around?
<plasticmillion> Hannibal: yeah, if the initial premise is that we need to use hacks to get it work then that doesn't really convince me to abandon my stance
<Hannibal> plasticmillion: 'tough shit' :)
<Hannibal> sorry.
* dria (dria@moz-B7FD1F7E.cpe.net.cable.rogers.com) has joined #developers
* KaiRo (robert@moz-F2134722.gumpendorf.xdsl-line.inode.at) has joined #developers
<Pike> Hannibal: somehow the term "localize" in there doesn't make sense anymore, we're in major localization freeze. I don't see us adding new features with l10n impact anymore
<Hannibal> seriously, I think it'll be hard/impossible to change a really basic functionality of the current set of interfaces in the way you're asking.
<Pike> but I should probably look at the bug before?
<Hannibal> Pike: that's what I just said, right? It'd not be there on branch or return NS_ERROR_NOT_IMPLEMENTED
<Hannibal> what we're talking about is not on bugs yet.
<Pike> ah
* Hannibal sighs.
* mcsmurf (chatzilla@moz-236B8DA6.dip.t-dialin.net) has joined #developers
<Hannibal> it's 5.15 in Cali, bah :(
<Hannibal> so...
<Hannibal> plasticmillion: so what about everything else?
<Hannibal> I was under the impression you didn't like the rest of my replies either ;)
<plasticmillion> no, but we're not done with the first one yet
<plasticmillion> are you intending to keep the same contract ID for the new service?
* glazou (daniel@moz-B0788973.clients.easynet.fr) has joined #developers
* glazou is now known as glazou_sick
<plasticmillion> Hannibal: I'm sorry but "tough shit" is not a particularly reasonable response
<glazou_sick> LOL
<Hannibal> plasticmillion: yeah, I said sorry. I meant that. Er, seriously though. I don't see what you're asking for happening.
<plasticmillion> Hannibal: again, are you intending to keep the same contract ID?
<Hannibal> and no, I'm not keeping the contract id but the current service will probably stay around
<plasticmillion> okay, so existing code will be using the old implementation with the cache, won't it?
<plasticmillion> I'm not sure I understand the issue
<Hannibal> I'm not sure I do.
<mcsmurf> !seen gerv
<firebot> gerv was last seen 4 weeks, 2 days, 15 hours, 16 minutes and 32 seconds ago, saying 'If someone needs more info, mail me.' in #developers.
<mcsmurf> !seen hecker
<Hannibal> I'm trying to tell you 'no' and give a better reason than "I don't have the time for it"
<firebot> I've never seen a 'hecker', sorry.
<mcsmurf> ok, i guess i'll rather use IRC to contact them :)
<mcsmurf> err
<mcsmurf> E-Mail!!
<mcsmurf> :)
<plasticmillion> Hannibal: I'm not sure what is the best way to proceed here
<plasticmillion> I've had my eye on that bug for a very long time
<Hannibal> there are ways to proceed?
<plasticmillion> I had no idea that someone was picking it up until very recently
<plasticmillion> and I believe that if we are building a platform here, then getting input and requirements from extension authors like us is vital
<plasticmillion> but now what I am hearing is "we don't have time for any of your comments and feedback"
<plasticmillion> and I believe the platform will suffer for that
<plasticmillion> I offered to offer you help and resources
<Hannibal> and I can't take them.
<plasticmillion> to give you help and resources, I mean
<plasticmillion> why exactly can't you?
<Hannibal> well, AIUI the google TOS and whatever, I'm supposed to do the work.
<Hannibal> so writing a spec and having someone else implement it doesn't count.
<Hannibal> additionally, I have my doubts if delegating that work and getting it back done will happen within a week
<glazou_sick> myk: ping
<Hannibal> which is about the time we have left.
<plasticmillion> we haven't even figured out exactly what the work is yet
<Hannibal> hence why I have doubts.
<plasticmillion> specifically with regard to the cache, I don't understand the issue and I don't understand why it represents extra work
<glazou_sick> §whois myk
<glazou_sick> er
<Hannibal> glazou_sick: nice. :)
<glazou_sick> isn't it ?
<glazou_sick> I am so exhausted I cannot type
* Hannibal will ask how glazou managed that some other day.
* wolfiR (stark@moz-6C19808.suse.de) Quit (Quit: Leaving)
<Hannibal> glazou_sick: :(
<Hannibal> get better sooN!
<plasticmillion> FWIW, I can't help but think that taking vital platform functionality and doing it in a total rush with limited resources is a dubious approach
<Hannibal> er, soon!
<plasticmillion> but I guess nevermind
<Hannibal> plasticmillion: I didn't ask for this, thank you very much.
* Hannibal points at timeless.
<glazou_sick> Hannibal: that's the plan, yes :-/
<plasticmillion> okay, well we have two options
<Hannibal> I wanted to do what the summary of the bug you CC-ed to says.
<glazou_sick> after almost 5 days at home unable to walk, I need to feel better :-/
<plasticmillion> Hannibal: like I said, I believe that gathering input before implementing is important
<Hannibal> and several people went "but then that spec will die and the world will be a worse place to live in"
<Hannibal> plasticmillion: so what the hell do you think I'm doing!
* Hannibal has done nothing else the past 2, 3 days, even.
<Hannibal> for this bug, anyway.
<plasticmillion> basically if the service is caching messages then it's useless as a general-purpose logging service
<Hannibal> that's not true.
<Hannibal> it's harder to use for your specific purposes.
<Hannibal> people use it right now, in precisely that way, so what you just said is just rhetorics.
<plasticmillion> also it's poor design since any caching functionality should be separated from dispatching
<plasticmillion> hello?
<plasticmillion> weird, it dropped my message
<Hannibal> what did?
<plasticmillion> nm, not sure what happened there :-)
<Hannibal> or rather, what message :)
<plasticmillion> anyway
<plasticmillion> I can't see a good argument for keeping caching and dispatching in the same service except for compatibility reasons
* Hannibal suggests he tries adding nsIException to nsIScriptError and everybody except timeless will be happy.
<plasticmillion> though I'm happy to have that discussion from a software design standpoint
<plasticmillion> it's just a legacy thing
<plasticmillion> I still don't really understand what the plan is in terms of backwards compatibility
<Hannibal> we really don't have the time for this kind of debate and it's just too late to do everything Right on branch right now.
<plasticmillion> okay
<Hannibal> "don't break external code using our code"
* dave (dave@E4A53FE4.6FCBF7A7.568276F.IP) Quit (Quit: leaving)
<plasticmillion> I believe that it would be very easy to preserve compatibility and do the new service correctly
<Hannibal> not breaking internal code would be self-evident, I'm assuming.
<Hannibal> plasticmillion: not. on. branch. in. 1. week.
<Hannibal> does that make sense? :(
<plasticmillion> I guess I could assess that better if I understood what the compatibility issue is
<plasticmillion> existing code will be using the old code, yes or no?
<Hannibal> no.
<Hannibal> well
<Hannibal> what existing code?
<Hannibal> ours or other people's?
<plasticmillion> the existing console service
<plasticmillion> anyone using the existing console service
<glazou_sick> !seen myk
<firebot> myk was last seen 4 hours, 40 minutes and 48 seconds ago, saying 'hmm' in #developers.
<Hannibal> probably not.
<Hannibal> at least, not /everything/
<Hannibal> I'm not 100% sure about that even!
<plasticmillion> so the new service will have the same contract ID as the old service?
<Hannibal> no, we can't do that.
<Hannibal> so a new contract id.
* mw22_sleep (chatzilla@moz-699295AA.dsl.snfc21.pacbell.net) has joined #developers
<plasticmillion> okay, so when people get the service with the old contract ID, what do they get?
<plasticmillion> today's implementation?
<Hannibal> the old service.
<Hannibal> yes, I guess.
<plasticmillion> okay, so where is the issue with backwards compatibility again?
<Hannibal> how do the new and old service interact?
<plasticmillion> since any consumers that exist today will stil be using exactly the same code
<Hannibal> do people using the old service get messages sent to the new service?
* fyysik_v (vision@moz-2615EBD6.host1.trt.starman.ee) Quit (Ping timeout)
<Hannibal> "where is the issue"
<plasticmillion> well, one option is just to leave the old service as is
<Hannibal> argh.
<plasticmillion> but otherwise, it can do the caching and delegate the messages to the new service
* plasticmillion also "arghs" :-)
* NeilZZZ (neil@moz-228E8524.lutn.cable.ntl.com) Quit (Ping timeout)
<plasticmillion> that was my original point
<plasticmillion> there's absolutely no reason for the new service to do caching
<plasticmillion> to have it *not* do something isn't more work, it's less wortk
<plasticmillion> work
* mw22_sleep is now known as mw22
<Hannibal> erm, that's oversimplifying things
<Hannibal> so
<Hannibal> I send a message to the new service
<Hannibal> that won't cache it
<Hannibal> but the old service will have to?
<Hannibal> that's... weird
<plasticmillion> yep
<plasticmillion> it's not weird because the way the old service does it isn't the right way
<Hannibal> what happens when people listen to the old service? Do they lose info?
<plasticmillion> well, it can implement the listener interface for the new service
<Hannibal> "Right Way" and "1.8 branch" are like Ann Coulter and european socialists.
<plasticmillion> and if people want it to capture "new" messages they just register it with the new service
<Hannibal> seriously.
<plasticmillion> sorry but I still don't see how this represents additional work
<Hannibal> the mere fact that I'm discussing it with you is additional work
<plasticmillion> anyway, at the end of the day I'm more willing to write our own service and duplicate code and effort than to make a nuisance of myself
<plasticmillion> for the record I'm unhappy and I don't agree with the way this is going down
<plasticmillion> I know it isn't your fault
<plasticmillion> I still like you :-)
<Hannibal> for the record, I'm unhappy and I don't agree with the way this is going down either.
<Hannibal> that doesn't help us though.
<plasticmillion> but it's ashame because I don't think that the perception that extension authors are important and should have a major voice has sunk in yet
<plasticmillion> okay, well good luck with your project
<shaver> I really wish we could compile or execute "major voice"
<shaver> I would have so many fewer problems
<plasticmillion> ah shaver
<plasticmillion> I knew something was missing in this debate ;-)
<Hannibal> shaver: did I wake you up? :|
<plasticmillion> anyway, it's okay, I already caved
<shaver> the two of you have different goals here
<shaver> which is why you're having such trouble finding a common solution
<shaver> Hannibal needs a way to find the document associated with an error
* NeilZZZ__ (neil@moz-228E8524.lutn.cable.ntl.com) has joined #developers
* Pike wonders what he has to do to his sent folder to actually accept messages every now and then
<plasticmillion> I know this sounds fatuous but my main goal is for Mozilla to be the best platform possible
<shaver> you need, AIUI, a general purpose logging system with the capability to provide some sort of additional context for stacks, though I'm not sure exactly what
<shaver> more vacuous than fatuous, I think!
<plasticmillion> heh
<plasticmillion> the extra context thing is Nice to Have
<plasticmillion> I wouldn't go to the mat for that
<plasticmillion> by the idea that a logging service should cache everything that goes through it is a showstopper
* NeilZZZ__ is now known as NeilZZZ
<shaver> well
<shaver> it turns out that the caching it does today is very important
<plasticmillion> it's really easy to register a listener and have it do the caching
<shaver> uh huh
<shaver> that's lovely for errors that are reported after the listener is initialized and registered
<shaver> it's not so lovely for errors related to registration or early init
<shaver> which is why console service is in xpcom, and not toolkit or xpfe
<shaver> does it have to be the same caching model as today? not necessarily
<plasticmillion> okay well this is turning into a rational discussion which I like :-)
* fyysik_v (vision@moz-BC76B658.host1.trt.starman.ee) has joined #developers
<shaver> I was looking in my bugmail for discussion on this, and didn't see any
<plasticmillion> sorry, I emailed Hannibal directly
<NeilAway> I don't suppose anyone knows an easy way to format a floating-point number to 2dp in JS only?
<Hannibal> I forwarded your email, so that's alright.
<Hannibal> NeilAway: toPrecision
<plasticmillion> I was reading the scrollback this morning and I thought he said for people to email him
<shaver> NeilAway: .toPrecision
<plasticmillion> so you think it would be too late to register a caching listener in xpcom-startup?
<shaver> if you've had your eye on this bug for so long, and the values-of-locals and caching issues are so important, though, I do wonder why you didn't say so in the bug during that "long time"
<Hannibal> plasticmillion: I also specifically asked you to post to dev.platform, though I admit it was wrong for me to ask for emails.
<shaver> plasticmillion: I thought I asked for a wiki page and/or dev.platform post
<plasticmillion> okay, my bad on the email but let's not get sidetracked
<shaver> plasticmillion: but I might have been hallucinating under the medication
<Hannibal> shaver: plan B from JS?
<Hannibal> (re: your email)
<NeilAway> .toPrecision is 2sf, not 2dp?
<shaver> Hannibal: plan B from the error reporter
<shaver> NeilAway: there's another .toWhatever
<shaver> toFixed?
<plasticmillion> shaver: I'm still planning to post to the wiki with a proposal for the symbolic info in the stackframe, which was what we were discussing yesterday
<plasticmillion> just haven't had time yet
<shaver> plasticmillion: permit me to propose an alternate approach?
<plasticmillion> permission granted
<NeilAway> shaver: marvellous
<shaver> thank you, my liege!
<plasticmillion> :-)
<shaver> I think what you really want is a headless "debugger"
<Hannibal> if shaver's right, ask timeless about jsdb?
* NeilAway hopes that's his "stupid question" quota for the month
<shaver> a "diagnostics extension", if you will
<plasticmillion> assuming that's true, what conclusion do we draw from that?
<shaver> it would let you log additional stack and context data
<Hannibal> shaver: so plan B from http://wiki.mozilla.org/User:GijsKruitbosch/JS_Debugging/DocumentFromException ?
<shaver> Hannibal: yeah
<Hannibal> right.
<shaver> Hannibal: low, fast, hard
* Hannibal heaves some sighs of relief.
<shaver> I think that "dump the locals" is probably not what you will generally want, and you'll want to be able to do things like get certain members of things on the stack, or check to make sure that the thing you get is registered, etc.
<Hannibal> I don't follow you on that one.
<plasticmillion> shaver: hold on, you changed the topic
<plasticmillion> weren't we talking about cachign?
<plasticmillion> caching
<shaver> plasticmillion: we were, but I don't have a good answer for caching yet
<shaver> I don't think xpcom-startup is early enough
<plasticmillion> I'm keen to discuss the headless debugger issue also and your line of reasoning is very interesting
<shaver> I just wanted to point out that the current caching model is not _just_ a case of poor design
<shaver> and solves a hard problem relatively well
<plasticmillion> yes, you succeeded in making that point
<shaver> so the headless debugger would register with the same hooks as venkman/firebug
<plasticmillion> my point is that if we are going to have something called nsILogService then it makes sense to make it as simple as possible and layer other stuff on top
<shaver> yes, that's fine
<plasticmillion> especially since caching everything obviously has major implications on e.g. memory consumption
<shaver> I agree about the interface, though we do need some way to get "early" messages out
<shaver> plasticmillion: not if we log, f.e., to disk
<shaver> anyway
<plasticmillion> yes, we are mainly planning to log to disk
<plasticmillion> okay, let's put that on ice for a bit... I'll give the "early message" issue some though
<shaver> I don't have a solution there. we need a way for listeners to easily get all the messages that came "before" them, ideally through the same interface
<shaver> memory consumption and reliability are both concerns
<plasticmillion> okay, so is your premise that the headless debugger will log stuff through the log service, or is it something totally separate?
<shaver> one of the actions that the debugger could take is to log something
<mcsmurf> NeilAway, do you know if something major changed in SeaMonkey in the "make SeaMonkey default app for browsing/mail/news"?
<mcsmurf> between SeaMonkey 1.0 and trunk
<shaver> plasticmillion: I would very much like to have your proferred developer take a swing at something like that, though I suspect that most of it can be done in JS
<shaver> plasticmillion: and I think that it would be a tremendous boon to diagnosing problems in apps and extensions alike
<plasticmillion> shaver: okay, but then how do I preserve symbolic info when I log something?
<shaver> what symbolic info do you want to preserve?
<plasticmillion> the only thing that occurs to me is the values of local and global variables
<shaver> (I'm going back to be in 10 mins, by the by)
<shaver> you fetch that in your headless-debugger action
<shaver> and log it
<plasticmillion> it seems natural to me to put that in nsIStackFrame since it is part of the stack frame e.g. in Win32 DbgHelp and in JSD
<mcsmurf> NeilAway, hm strange...forget that question for now :)
<shaver> it's not part of the stack frame, though
<shaver> not what you want
<Pike> plasticmillion: should objects be logged, and if so, in which depth?
<shaver> right
<shaver> what's in the stack frame is a reference to some object
<shaver> what you want is some set of information about that object, not the reference
<shaver> what's in the stack frame is EIP, SP, etc.
<shaver> the debugger analyzes that as you ask it to
<shaver> and I propose a similar model here
<shaver> jsd and windbg can both show you the source for the function corresponding to a frame, too, and I don't think we want that captured in the stack frame object
<plasticmillion> okay, true enough
<shaver> now, I do think that the stack frame should have enough information that a debugger (possibly headless) can *get* that information
<plasticmillion> any ideas on how to achieve that?
<shaver> plasticmillion: run some thought experiments for me while I drug myself into a com
<shaver> plasticmillion: well, I think we already have the pieces
<plasticmillion> well in my imagination I have a XUL window that I have registered as a log listener
<shaver> plasticmillion: go back over the bugs that you're thinking of where this information would have been valuable
<shaver> no, no
* fyysik_v (vision@moz-BC76B658.host1.trt.starman.ee) Quit (Connection reset by peer)
<shaver> XUL windows don't register as log listeners; for a design purist you do like to mix those layers! :)
<NeilAway> shaver: would you be surprised that rods tried and failed to roll his own version?
* glazou_sick is now known as glazou_afk
<plasticmillion> shaver: okay you lost me
<shaver> NeilAway: toFixed is a relatively late comer
<plasticmillion> surely the JS console is a XUL window that listens to the console service
<shaver> no
<shaver> or shouldn't be
<NeilAway> mcsmurf: not as far as I know
<shaver> the JS console is a component (model) that listens to the console service, and displays (view) the things it gets in a XUL window
<shaver> anyway
* markp (markp@moz-D6F51198.rmo.bellsouth.net) has joined #developers
<shaver> go over those cases you had in mind when you were thinking you wanted globals and locals and stuff
<plasticmillion> okay I imagine having a datasource of some sort that listens to the log service and is externalized in a XUL window
<shaver> and write our some commands that you would enter into venkman to get that data
<plasticmillion> I want to be able to go to a specific message and open it up in the tree
<plasticmillion> and see a stack
<shaver> write them down
<plasticmillion> then open a stack frame and see all the variables
<shaver> specifically
<shaver> which variables, to what depth
<shaver> you do not want to log all global variables on every error, let me assure you!
<shaver> anyway
* raccettura (raccettura@moz-B3D97F32.hsd1.nj.comcast.net) has joined #developers
<shaver> I'm going back to bed now
<shaver> write down the cases, and the data you need
<plasticmillion> well there can be two nodes, local and global
<plasticmillion> write them where?
<shaver> start a wiki page about automated diagnostics or something
<plasticmillion> the wiki?
<plasticmillion> okay I will
* raccettura (raccettura@moz-B3D97F32.hsd1.nj.comcast.net) Quit (Quit: Leaving)
<Hannibal> wiki.m.o willdo
<Hannibal> shaver: thanks for dropping in
* plasticmillion will think about the "early messages/caching" issue as well
<plasticmillion> yeah shaver, thanks
<Hannibal> shaver: and get well soon!
<plasticmillion> hope you feel better!
<shaver> Hannibal: hopefully!
<NeilAway> shaver: it says 1999 in cvs blame, so that gives rods two years to find out about it
* coop (ccooper@moz-E22D3B6F.sympatico.ca) has joined #developers
* coop (ccooper@moz-E22D3B6F.sympatico.ca) Quit (Quit: coop)
<Hannibal> plasticmillion: and just so we're clear, I'm not implementing that interface at all anymore, apparently. So that's that :)
* coop (ccooper@moz-E22D3B6F.sympatico.ca) has joined #developers
<plasticmillion> Hannibal: what interface is this?
<Hannibal> the ones we were discussing about.
<plasticmillion> ah ok :-)
<Hannibal> the idl file ones :)
<plasticmillion> I'm not unhappy with that solution
<plasticmillion> as long as you aren't either!
<plasticmillion> plus no one ever called me a "design purist" before
* plasticmillion is flattered
<plasticmillion> I'm usually the go-to-guy for ugly but clever hacks