[V4RB] design of future pluign

[Charles Yeomans]

On Wednesday, May 21, 2003, at 02:35 AM, Ruslan Zasukhin wrote:

> on 5/21/03 1:36 AM, Charles Yeomans at yeomans at desuetude.com wrote:
> [snip]
> 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.

Of course.
>
>> 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?

Perhaps, depending on the price.
>
> 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.
>

I think that we can do it better by not using DLLs.  What I want is the 
ability to use both local and remote databases in the same application. 
  Otherwise I don't see an easy way to write applications that have 
intermittent database connections.

Charles Yeomans