Tony Eviston wrote: > > Just a few random thoughts about the mythical project: > > I don't think it is necessary for the user side of the application to be > opensource, but that the database schema and any stored procedures do > need to be copyright to the project and able to be licenced for > commercial use with certain constraints - mainly to do with the database > admin user password being available to the purchaser of the software to > allow free data export and migration to another version if desired.
As long as it was still possible to create alternative front-ends/user interfaces, possibly open sourced. However, a LOT of the the effort would need to go into the front-end design, and it would be a shame to close off that front-end to third-party plug-ins and innovation by going down the closed-source route for it. > Hopefully the application can be heavy on stored procedures with a bit > less business intelligence in the other layers. Stored procedures, especially extensive use of them, mean being locked into a single SQL database product (even if it is an open source one). A three tiered design in which bog-standard SQL is used for the back-end, allowing multiple SQL database products to be substituted, and the storage business logic is all contained in a middle layer. Actually four layers may be desirable, with the user interface logic and the actual user interface also separated (but that is a natural consequence of MVC [model-viewer-controller] or related software patterns for user interface design). > I think it is desirable that the development of a windows version not be > constrained by linux optimization constraints and vica verca. ie there > will probably be 2 or 3 versions of the application for *nix, mac and > windows. In that case separateing out the storage business logic and user interface logic into their own layers is even more important. > The applications will be most similar at the database schema > level but even the schemata need not be identical twins (? triplets) if > the project has control of the schemata and can readily develop data > export-import routines. I'm not sure how we constrain the different > versions from storing data outside of the official database (thereby > reducing portability) but surely there is a way. > > One of the best outcomes in my view would be for a schema to be > published and very quickly licenced to a commercial vendor. This would > inevitably be for a windows version but I believe it would give the > whole project the momentum needed. It may also provide an income source > for development of the FOSS side. Schema (and even more so the business logic associated with them) are fairly easy to dream up but really hard to perfect. My feeling is that things need to be tried in practice. Also, the unanticipated requirements of business rules and user interfaces almost always means that back-end schema chnages or aditions are needed. In other words, the separation between front-end and back-end is never as neat as one would like - they are necessarily coupled not just at run-time, but also at design-time, and the back-end does not always drive the front-end (something which the openEHR crew haven't fully appreciated yet, I suspect). > Whilst my personal preference would be for a linux server I think I > would be happy with a windows client, and if a commercial version did > what I wanted I wouldn't mind paying for it. > > .Net 2.0 does look very good in that it has a lot of labour saving > classes built in, and it would be unwise I think, to design a project > that did not cater for it (if desired by a licencee of the schema). I agree, as long as Mono compatibility was kept in mind so that the .NET stuff could be ported to Linux easily. > So in brief we would be marketing a database schema, presumably branded > and trademarked and adequately marketed to our target audience. > (That's probably the answer to the problem of non-conforming data > stores - in order to market their product under the "Powered by xxxxx" > label the licencing vendor has to constrain their data storage to (a) > the licenced schema and / or (b) provide full export of other data to an > agreed open format.) Definitely a model worth considering. The problem is developing a back-end schema which is sufficiently useful to a commercial developer to be able to be marketed in the way you describe. The other things to bear in mind are: a) the object-oriented approach to software development is now fairly dominant, and it does work, and in that approach one develops a classes which encapsulate data requirements and the methods which operate on them. Not really fundamentally different from an SQL database schema and associated stored procedures, but there are nevertheless differences. In other words, most commercial developers woudl be looking for a design expressed as a set of UML diagrams etc, not as a E-R diagrams and a set of stored procedures. b) the openEHR people are barking up the right tree in their pursuit of multi-level systems "soft-coded" systems (which are not really a new concept, but openEHR brings some not-quite-complete rigour to the idea). In this view, hard-coded back-end schema are out and instead data requirements (and to a lesser extent at this stage their behaviour) are expressed as archetypes which mere mortal clinicians can work on and evolve as needs change. So what becomes important is a rather high-level database schema which is fixed, but which is also extensible and modifiable in all its details via software-coded data specifications. We have been doing something similar with respect to our Web-based public health data collection and management tool (it has a core schema to accommodate cases and contacts of communicable diseases, but user-definable - or admin-definable - data forms can be slotted into that schema and modified on-the-fly through a point-and-click interface). It is a powerful idea. But getting the the more fixed high-level schema right is not at all easy for the reasons I mentioned above - the user interface ends up having a lot to say in the design of that back-end data model/schema. > I realise this is not a model FOSS project but I believe it has better > prospects of generating sustainable activity. Agree that it is important to consider a range of models, although are any existing commercial software developers likely to be interested in such a fish-nor-fowl model? That's not a rhetorical question - I really don't know. Tim C > Tony Lembke wrote: >> >> On 22/09/2006, at 10:18 PM, Horst Herb wrote: >> >>> If you are still in doubt whether browser based web-apps can be as >>> responsive >>> and rich as desktop apps, check >>> >>> http://www.google.com/webhp?complete=1 >>> >> >> As I understand it the original Gnumed model as proposed by Horst 100 >> years ago called for >> 1) a rock solid medical database schema and engine >> 2) an API to interact with (and protect) that database >> 3) a simple method to allow developers to create customised GUI >> widgets calling those APIs >> 4) which would then allow anyone to create clients with a customised >> look, feel and functionality by arranging the widgets of their choice, >> in the GUI of their choice.(in a slightly similar way that you can >> customise your google home page <http://www.google.com/ig>) >> >> This has appeal because 'programmers' can do (1) and (2), 'scripters' >> can make and share (3) and then everyone can do (4) >> >> Ruby-On-Rails would appear to be one excellent option for (3), as it >> also allows (4)! >> (and, of course, anyone could also use wxPython or Cocoa or anything >> else they liked for (3), interacting with the same database) >> >> However, I think we'll be waiting for Web 3.0 till we get the GUI >> functionality of our current systems in a browser. >> Or, Horst, are you more optimistic than that? >> >> BTW >> Google Calendar, Writely and Basecamp (by ROR's David Heinemeier >> Hansson) are other excellent examples of AJAX functionality. >> <htto://calendar.google.com> >> <http://www.basecamphq.com/> >> <http://www.writely.com> >> >> >> Regards, >> >> Tony Lembke >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Gpcg_talk mailing list >> [email protected] >> http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk >> > _______________________________________________ > Gpcg_talk mailing list > [email protected] > http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk > _______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
