We have a similar plug-in framework that relies on BPLs. We have a smaller number of clients (but still thousands), and we do have the advantage of a good intranet, so the uploading of new BPLs is not really an issue for us.
We force clients to upload and use the most up-to-date version, so we have no versioning nightmare. If they are using it, then it is the most up-to-date version. However, we have minimised the amount that needs be downloaded by a single client. We have divided the BPLs into two groups. Those plugins that are only needed if they are used by the user, and those that are required by other plugins. The required plugins are forced to update, but the on-demand plugins are only updated when they are used. This works very well for us. I don't know if you have a similar enough situation to be get the same experience. Also, you do not have to re-compile those BPLs that are dependent on a changed BPL for minor changes. You only need to do it when you have changed done something like added a method, which has changed the object's VMT. You do not have to recompile for extra logic in the xxxx() method. If you have changed the VMT, then you will want to re-compile anyway, because of course objectA.1 has just become objectA.2 It does mean that you need a reliable method of tracking dependencies. We have a utility that parses our source code and works them out. Samuel -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Max Nilson Sent: Thursday, September 09 2004 3:12 p.m. To: 'NZ Borland Developers Group - Delphi List' Subject: RE: [DUG] Passing Objects to a DLL Phil Middlemiss said: > Good idea, although I'm not so worried about speed. Comparing > class type names may be slower, but it is certainly easier to > code than to build up a VMT translation table! Still, I'll > try and remember that idea in case of later development needs. If its one thing we do not have a shortage of at this time is CPU power. Using a few cycles comparing two strings is not going to cause much of a slow down at all, and if it does this would indicate that the code in question is using far to many class type interogation and should be redesigned. I've been thinking some more about the versioning issues you had with bpl's, and while I realise that this would be a serious problem for a distribution of your size, Borland did not do things their way with a very good reason. By assuming class matchs based on the names stored in the VMT's (ie. the class name) you are taking it upon yourself to guarentee that there will never be any mismatches between the VMT in the application and that in the plugins. I can see that if you are not extremely careful about versioning you could end up with some very hard to debug situations were the actual class did not match. In fact this entire object versioning mess is exactly what COM was invented to try and avoid (see "Inside OLE2" for more on this). As you said Borland's BPL technology satisifies the basic portion of the shared objects in separate files problem, but cannot handle the versioning issue without a full recompile. COM handles it perfectly at the expense of having to cater for a serious sick history of backwards compatibility. Without looking further into exactly what you were doing, and how and why I can't make any judgement about wht you should do to improve the situation. It's the sort of architecture vs pramatism problem that can cause my pain in an company. Cheers, Max. _______________________________________________ Delphi mailing list [EMAIL PROTECTED] http://ns3.123.co.nz/mailman/listinfo/delphi _______________________________________________ Delphi mailing list [EMAIL PROTECTED] http://ns3.123.co.nz/mailman/listinfo/delphi
