[V4RB] design of future pluign

[Robert Brenstein]

>  >
>>  When we say "local work for Valentina" we mean usage of EMBEDDED Valentina
>>  engine, when your APPLICATION have inside of self Valentina.
>>
>Rather than have two code bases (embedded and distributed), have a single
>code base (distributed) and control the usage via licensing. This means
>that:
>
>1)  you have one model for each of your products;
>2)  we write our solutions once and it handles both the single user case and
>the distributed solution;
>3)  the customer moves easily from single user case to multi-user case by
>simply re-licensing the Valentina server from 1-person to as many as needed;
>this is the ultimate in scalability.
>
>If you proceed with the two model approach (embedded plus server) then, as a
>developer, I need the ability to talk with the embedded database plus the
>server. I would like to do this without maintaining two code bases (embedded
>+ server) which do exactly the same job. I understand that this goal might
>not be possible in this case; however, it would be very nice. :)
>
>John Roberts
>

It would be great to work with a single codebase but embedded offers 
better performance and reduced support as far as I can tell. You must 
also keep in mind, John, that Valentina is used quite differently by 
different developers. For example, if I use it as an db engine on my 
webserver, I surely prefer to work with embedded version rather than 
having a separate app that my cgi has to talk to (particularly when 
working under OS9). Further, I do not think that in reality having a 
single code will work so simply as you seem to envision. In case of 
Valentina server, when we have a network between the client and the 
database, there are more potential errors and issues to tackle in the 
code. And I somehow do not forsee too many apps that require exactly 
same functionality for local and remote work. Mixed pull-push model 
as described by Cindy may be more common aside from purely-local and 
purely-remote modes of operation. None of these would fully, truly 
benefit from having a single codebase. And you can of course add your 
own level of abstraction to unify your interfaces.

Robert