[V4RB] design of future pluign

[Keith DeLong]

I'd like to jump into this a bit on the late side... I'm confused and I need
some help understanding what you're saying here.
 
> Okay, answer me at first on the next question.
> 
> 1) forget for now about combo - app.
> 
> Let you want develop some App. It must have as Standalone so Client
> versions. How you see this ?
> 
> IF we have 2 different V4RB plugins, then you need compile one app, using
> first., and second app using second.

I don¹t care whether I have 1 or 2 plugins, but at a minimum they MUST be
able to live in the RB plugin folder at the same time.

I've already had regular troubles doing server work then switching to V4RB
1. X work and having applications fail, plugins mixed up (which is which),
both plugins left in at the same time .... It's not a good situation at all!

> So you now must distribute 2 (!!!) compiled applications.
> Agree?
> 
> 
> 2) As for me, I like idea in PrimeBase, when you make and distribute only
> ONE application. 

Me too. In my main V4RB app, users often buy a single version then come back
for additional licenses as they want to install other copies around their
network. Maintaining a single executable for local or client-server work is
really a great advantage for code maintenance and marketing reasons.

> Valentina work for local db as true embedded engine...but I like this
> idea...Or you think that it is normal if you will distribute 2 versions of
> your apps ?

I have a client-server app in development that has a fairly complex set of
local user options that I want to store locally in a Valentina DB for each
client. For this it seems I need both the standalone engine and client
engines built in.  
 
> 3) you self have point problem with above way.
>   How you will be able subclass Vdatabase? VCursor..

Can we not more logically have two distinct objects -- VDataBase for local
work (and legacy code) and VDataBaseServer for client access to a server?

Did I miss something??

Keith DeLong