On Mon, 2003-09-22 at 02:35, Rodrigo Moya wrote: <snip> > > The binary metadata cache idea I really like. The only thing I don't > > like is the requirement for a user to manually register plugins. The > > plugin system could take care of registering new plugins on startup at a > > slight first time load up hit. Its something I want, but could live > > without. > > > what do you mean by 'manually register'? > Something like, I copy my foo.dll mono plugin into the plugin directory, then I must execute something like "go_mono_register foo.dll" to register the plugin with the plugin system. In the current implementation, go_mono_register would generate a plugin description xml file from the dll. The application could be made to do this on newly installed plugins on startup rather then requiring the user to do it. rpm/deb post install scripts could do this too, so its not all on the user. But without the plugin system doing it itself, then you cant have it as easy as "Download this foo.dll plugin to your plugin directory and your all done" > > Proxy's are used in Gnumeric. Since most other people don't need it, we > > can just leave the code in Gnumeric. We shouldn't concern ourselves with > > them, other then realize that some people might want to implement them > > on top of GO. > > > hmm, it makes sense anyway to have an abstract class that implements the > proxy, if possible, and leave its usage as an implementation detail to > each service, right? > Its basically a ghost object for a service. It looks and works just like the service, but doesn't actually load the plugin that its ghosting until its actually used. This would require one proxy object per service type. Since apps are free to implement their own service types, I don't think we should make it a requirement for them to provide proxy object implementations since most apps wont ever use them. Maybe in the service class we provide a way to specify what proxy object implementation to use if the user requests a proxy. So, when the user asks for a foo service, he can ask at the same time for a proxy or a real object. If the service doesn't implement proxy's, then it will just return a real object. That way, apps that don't need proxy's can just not implement it... > > Jody and my discussion lead us to believe that plugins were not going to > > be shared. If they always are to be shared, then your right, there's not > > much need for changing the directories. > > > as I said in other mail, I think there are a few plugins that ought to > be shared. Of course, most will not, as they are going to be specific to > each app, but some like the scripting engine and the data acquisition > services make a lot of sense as shared. > Yeah. I agree now. > > > > Ok. This is the first good example I've seen. You've just convinced me > > that sharing plugins is in fact something that should be supported. :) > > > and the scripting engine :-) > I'm still somewhat unsure if the scripting engine really can be shared much. From Simulus, the code that actually embeds the different programming languages is relatively small. Maybe 10% of the scripting code. The other 90% is in the bindings which can't be shared between apps. I've still got to explore your idea of using the accessibility api for scripting though. I've played a bit with it, and I think it might work. The one thing that I saw though, is that it appears that it makes things very dependent on the layout of the app. If you change the GUI then the scripts wont work any more. Also, while not as important for GNOME, it wouldn't work nicely with nongui apps. > cheers cheers --- Bob Smith <bob thestuff net> --- ++++++++++[>+++++++>++++++++++>+++>+<<<<-]>++.>+.+++++++ ..+++.>++.<<+++++++++++++++.>.+++.------.--------.>+.>.
Attachment:
signature.asc
Description: This is a digitally signed message part