I have still not seen anything that looks remotely like a modern IDE This looks like state of the art ...
A look at Eclipse' new browser-based web development tool, Orion http://www.youtube.com/watch?v=yA_lsvKfv4I I remain unimpressed (in terms of what we might require) but happy to be pointed to a real, working example of a web-development tool which might replace and considerably augment current archetype editor, template designer functionality, without requiring some really arcane web-developer skills. What we should really do now is to establish the requirements for this second generation of tools. I am certain web-services will play a big part in repository integration and e.g validation/comparison services but still not convinced that the kind of rich GUI we require is deliverable quickly with HTML. Thanks all. Interesting discussion :-) Ian Dr Ian McNicoll office +44 (0)1536 414 994 fax +44 (0)1536 516317 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com Clinical Modelling Consultant,?Ocean Informatics, UK openEHR Clinical Knowledge Editor www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL BCS Primary Health Care ?www.phcsg.org On 11 September 2011 14:23, Erik Sundvall <erik.sundvall at liu.se> wrote: > Hi! > > I agree with Seref. Web based apps nowadays can use local storage in > modern web clients and even be run perfectly offline and sync when > they get back online. > > If effort is put into new tools it might be good idea to do at least > the GUI in HTML5 etc. The server could be any technology you want, > including Eiffel ;-), as long as it speaks http, if "normal" users > (including ones under IT policies of the institutions) don't need to > do a server install. > > Regarding editing power and repository integration have a look at some > examples like > http://c9.io/ > http://ace.ajax.org/ > > By the way, using Git as archetype repository sync backend at least > for non-CKM work (as hinted by Shinji) seems to be a really nice idea > the nore you look at it. The Git collaboration patterns and mentality > seem to fit the use-case of distributed multi-branched archetype > development. > > Best regards, > Erik Sundvall > erik.sundvall at liu.se http://www.imt.liu.se/~erisu/? Tel: +46-13-286733 > > > > On Sun, Sep 11, 2011 at 12:21, Seref Arikan > <serefarikan at kurumsalteknoloji.com> wrote: >> Peter, >> The problem is not necessarily about the capability of frameworks to >> manage updates or side by side execution. >> 90% of the time problem is about the IT policies of the institutions. >> If you develop with .NET 4.0, which would require a .net framework 4.0 >> runtime, you assume that the people using the software would be able >> to install the runtime, and install the software. >> many corporate/institutional machines do not allow their users install >> software. Most of the corporate/institutional IT is running on >> horribly old software. IT policy is the real issue I was referring to. >> I don't want to go into a long description of things that went wrong >> for me in the past, but let me just say that I've personally had >> enough issues with both Java and .NET deployment and upgrades that >> makes web based apps a much better option when it comes to this >> particular aspect of software life cycle. >> >> Regards >> Seref >> >> >> On Sat, Sep 10, 2011 at 2:18 PM, Peter Gummer >> <peter.gummer at oceaninformatics.com> wrote: >>> Seref Arikan wrote: >>> >>>> ... ?Unfortunately, most modern >>>> software development technologies arrive with their own runtimes, >>>> (.net framework, jre etc) and it quickly becomes a nightmare to deploy >>>> and update software. >>> >>> I'm not aware of any such deployment problems with .NET. I'm sure >>> there must be some, somewhere, but they must be edge cases. In ten >>> years of .NET development I haven't bumped into them. Different >>> versions of .NET sit side-by-side on the same machine just fine; ditto >>> for DLLs targeted towards different .NET versions. My daily work >>> involves a .NET 4.0 application that has dependencies on a lot of .NET >>> 2.0 DLLs; it just works seamlessly. >>> >>> - Peter > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical >
