Re: [fonc] Views in FoNC
Just tossing in a few words I'd like to see well supported: Distribution Deployment Installation Integration Upgrade (data/state migration, transition between dependencies, consistency guarantees, deployment of) History (cross cuts most things) Dependencies, Entanglement Version Control Merge Data persistence (e.g. schema, tables) Discussions (e.g. something like talk pages, user pages on wikis) Tasks, Priorities, Bug tracker I'm sure I've missed many. On Dec 8, 2012 8:10 AM, John Carlson yottz...@gmail.com wrote: So I was just designing a generic architecture presentation, and I came up with 5 different types of views. Are there more? Editor (programmer, designer, scripter) Debugger (programmer) Browser (end user, player, sharing) Configuration (setting property lists) Administration (ACLs, grant, revoke, capabilities, upgrading schema) What are the FoNC thoughts on supporting all these views? What's the best approach for children? On one of my projects, we combined the Editor, Debugger and Browser into a single view , which we called the workbench (or recorder), then we added views for various tools we wanted to incorporate. If we would have had a GUI builder, we probably would have had Configuration. What I don't know how to do is incorporate Administration, except by providing capabilities to share behavior and structure. How does the user interface for capabilities appear in FoNC? John ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Views in FoNC
On 12/08/2012 12:01 PM, David Barbour wrote: Just tossing in a few words I'd like to see well supported: Distribution Deployment Installation Integration Upgrade (data/state migration, transition between dependencies, consistency guarantees, deployment of) History (cross cuts most things) Dependencies, Entanglement Version Control Merge Data persistence (e.g. schema, tables) Discussions (e.g. something like talk pages, user pages on wikis) Tasks, Priorities, Bug tracker I'm sure I've missed many. I'd add attribution (with hopefully a fair degree of granularity). ~c On Dec 8, 2012 8:10 AM, John Carlson yottz...@gmail.com wrote: So I was just designing a generic architecture presentation, and I came up with 5 different types of views. Are there more? Editor (programmer, designer, scripter) Debugger (programmer) Browser (end user, player, sharing) Configuration (setting property lists) Administration (ACLs, grant, revoke, capabilities, upgrading schema) What are the FoNC thoughts on supporting all these views? What's the best approach for children? On one of my projects, we combined the Editor, Debugger and Browser into a single view , which we called the workbench (or recorder), then we added views for various tools we wanted to incorporate. If we would have had a GUI builder, we probably would have had Configuration. What I don't know how to do is incorporate Administration, except by providing capabilities to share behavior and structure. How does the user interface for capabilities appear in FoNC? John ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Views in FoNC, FoNC in organizations
It seems like the more views we create, the more jobs we create. Perhaps we should be grouping views into skill sets, interests, or organizational roles. What kinds of capabilities are required for each view and which type of people does the organization want manipulating the capabilities? That is, does our design of views determine organizational structure, or vica versa? Should the use cases be different for each organization? Is the acceptance of the software dependent on organizational use cases? What will make an organization succeed using FoNC? John ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Views in FoNC
I'm a bit confused - general architecture of what, exactly? Sorry if this is obvious. The organisation? The artefact that VPRI will eventually produce? or FoNC itself? What is a view here? It appears to be inverted for your use. Surely REASON comes before PROCESS, doesn't it? (That is, rather than focus on the processes, or applications that a user will be focussing on, why not focus on the things that the people are trying to achieve). That is, in the process going to the bank to get some money out, the reason is surely king - it's the driver... and that's to get money out so I can go and buy food. Julian On 09/12/2012, at 3:09 AM, John Carlson yottz...@gmail.com wrote: So I was just designing a generic architecture presentation, and I came up with 5 different types of views. Are there more? Editor (programmer, designer, scripter) Debugger (programmer) Browser (end user, player, sharing) Configuration (setting property lists) Administration (ACLs, grant, revoke, capabilities, upgrading schema) What are the FoNC thoughts on supporting all these views? What's the best approach for children? On one of my projects, we combined the Editor, Debugger and Browser into a single view , which we called the workbench (or recorder), then we added views for various tools we wanted to incorporate. If we would have had a GUI builder, we probably would have had Configuration. What I don't know how to do is incorporate Administration, except by providing capabilities to share behavior and structure. How does the user interface for capabilities appear in FoNC? John ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Views in FoNC
Julian Leviston wrote: I'm a bit confused - general architecture of what, exactly? Sorry if this is obvious. The organisation? The artefact that VPRI will eventually produce? or FoNC itself? I was kind of wondering that myself. Particularly as VPRI seems to be working on multiple artifacts, and FoNC seems to be broad area of discussion, as opposed to fundamentals of a specific new computing system/architecture. Last time I checked - recently actually, for a proposal effort - one selects an architectural framework, and which views to present, AFTER one has some sense of what kind of architecture one is presenting, and for what purpose. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Views in FoNC
Would general software (and possibly hardware) architecture be better? If you want to throw a use case in, then I would choose MMO Game VisualTextualStored Language/Engine/Maker. View as in Model-View-Controller. I want to browse, play, edit, debug, administer, configure, ... discrete, differential and perhaps continuous games. I'd like Concrete Models to be implemented in a variety of formats/languages, databases and network protocols, and an Abstract Model, which can be interfaced with a variety of controllers and views. In other words, I think any game engine should be able to plug into this architecture, with some stovepiping, as well as any existing view from various game engines (2D, 2.5D, 3D, command line, etc). Ultimately, I'd like to define the MVC interfaces (not classes) for game engines. But perhaps someone has already done this? With my previous email, I am merely trying to categorize fundamental UI views to exist into groups...I didn't ask for a huge list, but something similar to how SQL has been broken down into DDL and DML, and further into individual SQL statements. Many types of UI views already mirror the language in the database. What other types of UI views are possible, and can we create an ontology of them? I haven't really figured out how shading languages fit into all of this. I probably need to spend sometime with them. On Sat, Dec 8, 2012 at 5:02 PM, Julian Leviston jul...@leviston.net wrote: I'm a bit confused - general architecture of what, exactly? Sorry if this is obvious. The organisation? The artefact that VPRI will eventually produce? or FoNC itself? What is a view here? It appears to be inverted for your use. Surely REASON comes before PROCESS, doesn't it? (That is, rather than focus on the processes, or applications that a user will be focussing on, why not focus on the things that the people are trying to achieve). That is, in the process going to the bank to get some money out, the reason is surely king - it's the driver... and that's to get money out so I can go and buy food. Julian On 09/12/2012, at 3:09 AM, John Carlson yottz...@gmail.com wrote: So I was just designing a generic architecture presentation, and I came up with 5 different types of views. Are there more? Editor (programmer, designer, scripter) Debugger (programmer) Browser (end user, player, sharing) Configuration (setting property lists) Administration (ACLs, grant, revoke, capabilities, upgrading schema) What are the FoNC thoughts on supporting all these views? What's the best approach for children? On one of my projects, we combined the Editor, Debugger and Browser into a single view , which we called the workbench (or recorder), then we added views for various tools we wanted to incorporate. If we would have had a GUI builder, we probably would have had Configuration. What I don't know how to do is incorporate Administration, except by providing capabilities to share behavior and structure. How does the user interface for capabilities appear in FoNC? John ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Views in FoNC
The reason is to keep my brain active. I like categorizing stuff. Here's another take on the same thing: Creating Habits Performing Behavior Introspecting Behavior Watching Behavior Controlling Behavior Protecting Behavior Sharing Behavior Criticizing Behavior Commenting on Behavior How many types of things can we do with behavior? Would this give us the views we want? On Sat, Dec 8, 2012 at 5:50 PM, Julian Leviston jul...@leviston.net wrote: On 09/12/2012, at 10:29 AM, David Barbour dmbarb...@gmail.com wrote: On Sat, Dec 8, 2012 at 3:02 PM, Julian Leviston jul...@leviston.netwrote: I'm a bit confused - general architecture of what, exactly? Sorry if this is obvious. The organisation? The artefact that VPRI will eventually produce? or FoNC itself? Based on the sample views, I assume an architecture for an integrated development environment. Surely REASON comes before PROCESS, doesn't it? Process does not happen before or after reason. Reasoning is part of the process. People often think with their fingers and bodies - tweaking, twiddling, learning, inspiring, a sort of brownian motion in thought space. The process (paradigm, language, architecture) makes certain kinds of reasoning more or less difficult, and thus less or more probable. LOL. a reason, not reason. Note I didn't say reasoning comes before processing. I meant a reason to do something surely must come before and inform a process to do. As in... the point of doing what you're doing. I thought this might be obvious from my example (I guess not?) Julian http://en.wikipedia.org/wiki/Nudge_(book) Regards, Dave ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
