> A little side node: You are regularily using "pretend" in a manner that > doesn't quite fit the context in English, and in fact is quite amusing > :-)
Ahah, checked that up on a dictionary, indeed, it's quite amusing ;-) > I don't think it's a good idea to define the interfaces in a completely > new way. This will create redundancy, with all the associated > disadvantages rdeundancy cretes. We better avoid the disadvntages of > reddundancy. I don't want to see the disadvantgaes of rdundancy creep > in. It would be quite cumbersome to deal with the disavantages of > redundany. The diadvan... well, I guess you get the point ;-) You are right, it may create redundancy but, wouldn't it be nice to define new interfaces without leaving lisp and then using them to create new servers only with lisp code? I'm not even talking about re-defining the already used interfaces in Lisp, but creating new ones. Or, you could even (possible with more work) replace some core servers with ones written in lisp... well I must stop before someone calls me a Smug Lisp Weenie :-P That's the advantages I have seen when I thought about that possibility ;-) > Rather, reuse the existing .defs, only creating Lisp interfaces from > them instead of C interfaces. That's a nice approach, I think. > BTW, what about the option of invoking the MiG-generated C stubs rather > than creating native stubs in Lisp; have you considered that? I'm not > saying that I think it's a better option; but I'd like to see a > discussion of advantages and disadvantages of redun^W^W^W^W^W err I mean > the advantages and disadvantages of both approaches... Using MIG generated stubs means less work but keeps you dependent on stubs generated on the C language. Using native stubs, well, you don't have to deal with MIG, which, sincerely, is not the best thing in the world :) > > (And in fact also for other approaches like binding to existing > libraries -- you now say that you want to do it this way as if was the > most normal thing in the world, but never explain your motivation for > that change... Don't leave us groping in the dark! :-) ) Well, when I sent my proposal, the initial goal was to develop two library bindings: one for libtrivfs and another for libnetfs. But, Neal Walfield expressed some disappointment that the Lisp bindings would not bind at a deeper level (namely, at the interface level) and then Pierre Thierry and I discussed about investigating these different approaches. Why I'll bind these libraries like libports? Well libports is currently used in libtrivfs and libnetfs and is needed to manage ports and listening to incoming messages. Also, I think it will be generally useful to have a Lisp library to libports. I'd like to hear more opinions on this :)
