On Sat, 2003-09-20 at 14:40, Rodrigo Moya wrote: > On Mon, 2003-09-08 at 03:41, Bob Smith wrote: > > > > > need to do this at start up. To date we've made the simplifying > > > > Thats something that needs to be addressed. Although, you could make the > > argument that you too are discovering the plugins on startup. You just > > only have one way of doing that. > > Jody and I spent a significant amount of time figuring out a common set of terms so we could describe what we need. Some of this email covers that. I don't know if your following paragraph asks me about a loader or a discoverer. Multiple discovery types would allow for things like storing the list of plugins on a server or storing plugin metadata in a .net dll. > hmm, sorry if it's obvious, but why do we need more than one way to > activate plugins? If we need to support several directories, we can have > a system-wide gnome-office.xml file that contains the list of > directories to search for plugins. > > > > reason for using that model instead of a pango-querymodules > > > approach. > > > > There's a few ways to do this: > > 1. Have a binary file that's all the plugin information boiled down into > > a nice fast single file that the plugin system could read. That would > > make startup the fastest. Plugins would need to be registered with the > > file when installed. > > > hmm, this sounds good. In libgda, we just use that way, instead of the > .xml file. We search in a given directory for .so files, and try to call > a set of defined functions that gives us enough information about the > plugin. > > I think this can be much better than accompanying the plugin with the > xml file. > Talking to Jody, the current way of loading up .so files to get the metadata is not acceptable to the Gnumeric folks. 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. > > > > > > > Notes: > > > > 1. Proxies. A lot of programs wont need proxy objects. Let the application provide them. > > > > > > What's a proxy ? > > > > An object that acts like a service but is just a wrapper around it so > > you can delay the loading of a plugin until absolutely necessary. > > > hmm, I guess this separation is already made with the Plugin->Service(s) > separation. Also, using a libgda-like way, there is no need for the > proxy, AFAICS. > 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. > > > > > > > One main GObject that deals with these features: > > > > 1. State property. > > > > 2. Add directory. State becomes PROCESSING. Idle callback to update metadata. > > > > 3. Remove directory. State becomes PROCESSING. Remove metadata. Idle callback to unload relevent plugins. > > > > 4. A function to get a list of directories. > > > Why are we talking about directories at this level ? If we're truly > > > going to abstract discovery isn't 'xml files in directories' an > > > implementation detail of the current form ? > > > > This allows the user of the application to give a hint to discovery > > objects where to look for plugins. Discovery objects are free to look > > elsewhere (for example, a web server). Ex, Three different plugin > > discovery mechanisms. One for R files, One for Mono and one for XML > > described plugins. They all might want to look in > > "/usr/share/gnumeric/plugins" and "/home/foo/.gnumeric/.plugins". A user > > might want to look for plugins in "/shared/gnumeric/plugins" too. This > > would inform all the discovery objects to look for their plugins in that > > directory too. > > > I think we can just have a set of default directories to look into > ($prefix/lib.../plugins, and ~/.gnome-office/plugins, for instance), > and, apart from the system-wide XML config file (where you can specify > new directories), and a way for client apps to add, at run time, other > directories, we are set. > 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. > > > > > > Why talk of idle handlers ? > > > > > > > So if things take too long to load, the GUI can be refreshed while it > > processes without the need of threads. > > > idle handlers give a lot of problems, when using many parallel calls. > The problem with using idle handlers is that apps, when calling the > plugins, will think it's synchronous, which it isnt, since you can, > while making the call, get a signal callback called, which breaks the > "supposed synchronicity". No. The idle handlers would only cover discovery and loading. Once you've gotten a service from the system, then its synchronous. (Or how ever the service is coded to work) > > > > > 1. A service almost never can be shared between apps, so > > > > information about them (Like metadata description, parsers, and > > > > display widgets) should usually be implemented in the application > > > > itself rather then a generic library. > > > > > > Agreed. Although I would add the notion that a plugin should be > > > able to add service types for other plugins to implement. > > > > > > yes, right, this is a great idea. > > > > > > > Service : An interface specification. > > > > Yes. > > > > > ServiceImpl : A factory that produces objects supporting a Service > > > I find this redundant. THat's exactly what the Plugin class does. Jody and I are making sure we have our terminology straight here. For example, what is a plugin? Is it a class? Is it a .so file? If you don't have your terminology straight, you cant discuss your needs. > > > This is a detail. My plugins don't need factories, they just need one > > instance of a service. If the instance of a service supports spawning of > > more objects like a factory, thats up to the service itself to decide. > > Maybe we should say, ServiceInstance. > > > > > Plugin : A blob that that contains implementations of services > > > > Taking ServiceInstance from above, > > Plugin: A blob that contains instances of services. > > > there can be a service which is for registering other service types, and > the Plugin class contains both these and the service implementations. > Yeah. > > > - Define plugins on a per application basis. Sharing them seems > > > like a very rare use case (?example?). > > > the data service is the best example so far. Since both gnumeric and abi > use libgda to get data... > 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. :) > > Agreed. I've thought about this some more and still couldn't figure out > > a good example of when they really would need to be shared. The way I > > described things in the doc though, it wouldn't be impossible to share > > plugins. You would just add a directory to the list that contains the > > shared plugins in each app sharing them. > > > I think we can just have each app query the plugin loader for the > plugins that implement the services it understands. Thus, the services > not supported/understood by the app wont ever show up in the plugins > manager dialog, for instance. I dont think we have to complicate things > more. > Yeah. Something like, Give me a list of services that are of type "foo" would work. > IIRC (dont have the GO sources here), there is code to do that "get me > services of this type". And if there isnt, we just need to add it. > > cheers cheers --- Bob Smith <bob thestuff net> --- ++++++++++[>+++++++>++++++++++>+++>+<<<<-]>++.>+.+++++++ ..+++.>++.<<+++++++++++++++.>.+++.------.--------.>+.>.
Attachment:
signature.asc
Description: This is a digitally signed message part