[V4RB] design of future pluign

[Ruslan Zasukhin]

on 5/21/03 1:36 AM, Charles Yeomans at yeomans at desuetude.com wrote:

>> 3) For Visual BASIC and for Director it seems also will not be huge
>> problems
>> to support this.
>> 
>>     But for REALbasic I still do not see a way.
>>     How to have in the plugin folder 2 V4RB and V4RB_Client plugins,
>>     and they should now conflict.
>>     Right now both have classes with THE SAME names, Vdatabase,
>> VCursor.
>>     and this kill idea.
>> 
>>     May be I will need make here also Interface classes,
>>     and subclass them. This kill 2 tagets. This interface classes
>>     then must be in RB code itself as separate module.
>>     This will be THE SAME RB classes that we have talk many times
>>     on RB list as general subset for any DBMS.
>> 
>>     So RB promise a lots of tasks on this way.

Hi Charles,

> I would also like the ability to use both local and remote databases in
> the same project.  If I understand you correctly, the idea would be to
> make VDatabase,  VCursor, VBaseObject, VField, and perhaps the VField
> subclasses into class interfaces.  These interfaces could be
> distributed as a collection of Rb class interfaces -- it probably
> wouldn't even be necessary to write a plugin for them.  Then the V4Rb
> plugin would have a class VDatabaseLocal , while the V4Rb Client would
> have a class VDatabaseNetwork (and also
> VBaseObjectLocal/VBaseObjectNetwork, etc.).  These classes could also
> implement the RBDB interface through inheritance, since RS appears to
> be utterly unresponsive to the idea that the RBDB API be written in
> terms of class interfaces.

Yes, all correct, Charles.
Let's the point. We can develop this DB interfaces directly in RB as module,
No need for plugin.

Look, this was think aloud.
I am not sure that we will go by this way yet.

> I think that this would work fine for databases with dynamic structure,
> but suppose one wants to use a static structure? That is, I should
> still be able to write subclasses of VDatabaseLocal, VDatabaseNetwork,
> etc.  This seems possible -- in fact, one could define new class
> interfaces that extend VDatabase, etc.  The only disadvantage is that
> if I want to use the same database structure with both local and remote
> databases, I would need to write essentially the same code for parallel
> subclasses of VDatabaseLocal and VDatabaseNetwork.

Yes correct. Thank you for point.

Today I have wake up, and get one more idea.
May be we ca solve this, but payment -- V4RB will be not single plugin as
know, but set 

        V4RB + VEngine.dll + Vclient.dll

Having this, I think I will be able
1) have the same set of classes as now
2) work as embedded engine or client
3) catch errors in case e.g. Client is absent but you ask create client
database.
4) work in combination with 2 DLLs.

Are you ready pay for such feature having additional DLLs for your app also?

I know that PrimeBase do this. Although they do it as ONLY ONE of them.
Primebase plugin for REALbasic, allow you COMPILE one EXE file of your app,
And on the fly you or your customer, can put any of this DLLs and fix some
ini file to choose if this app should work as standalone or remote client.

We can do this even better I think.

-- 
Best regards,
Ruslan Zasukhin      [ I feel the need...the need for speed ]
-------------------------------------------------------------
e-mail: ruslan at paradigmasoft.com
web: http://www.paradigmasoft.com

To subscribe to the Valentina mail list go to:
http://lists.macserve.net/mailman/listinfo/valentina
-------------------------------------------------------------