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.
Hopefully the application can be heavy on stored procedures with a bit
less business intelligence in the other layers.
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. 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.
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).
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.)
I realise this is not a model FOSS project but I believe it has better
prospects of generating sustainable activity.
Tony Eviston
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
