Hi...
On Thu, Feb 14, 2013 at 4:16 PM, Maurizio Taverna <[email protected] > wrote: > Hello, > I've been a Smalltalk guy (oh yes, I'm that old), so I watched with > interest to the video presentation. > What they did is really cool, and if you are a Smalltalk developer to > really enjoy it. > Thanks again to Adam for sharing. > > I would like to ask, what are we trying to get out of this ? And whom we > > are targeting ? Because answering these question is critical to what > > approach/tool(s) we want/will take > > > > It seems we all agree on one point. > The idea of providing a full features development environment online is a > huge work and out of scope. > I don't know any developer who will switch from his/her favourite fully > integrated IDE > to a 'limited' online environment. > On the other side I know very few non-developers with an IDE on their > computer, In my experience, just asking some like that to any IT manager > sounds like crazy request. > What I'm trying to figure out are the features of a workspace, shared > between users and developers, that allows to work together on the domain > model. > Centre of the picture there is the a version control system, integrated > with the IDE and the workspace. > The workspace should have access only to the domain classes, presented as > user interface. > They should be able to work with the model (with limited functionality), > as an interactive run-time, when done commit the changes, and the > developers from their favourite IDE can update the project and implement > the functionality. > As additional functionality the workspace could allow the users to enter > the data for fixtures, the business experts are usually pretty good in > providing a set of significant data. > Any feedback on this topic is very appreciated. > Aha, interesting, that indeed another different scenario than the two I have explained and indeed there is a very valid use case here, more over I like the idea of having the version control as the connection between the IDE and the workspace which abstracts the source of changes so semi/developers can see each other changes as if any other developer(s) made the changes and pushed/committed them to the repository I believe there a good consensus here then, why not to move the discussion to more technical details more specifically the central point caused based on that we can decide how and what to expose to the workspace cause from the IDE side it will just be commit/push operation I would like to see if we can "eat out own dogs food" that is: - Why not to think about the WIDE (Workspace IDE) to be an Isis RO client and the domain model exposed over RO is actually our programming model What do you think about that direction ? > Cheers > Maurizio > -- Thanks - Mohammad Nour ---- "Life is like riding a bicycle. To keep your balance you must keep moving" - Albert Einstein
