|
http://www.sellsbrothers.com/
Regards,
Barry
|
|
|
|
|
|
Chris Sells mentioned you before in a previous blog. I'm surprised you'd never noticed!!
Regards,
Barry
|
|
|
|
|
Barry Lapthorn wrote:
I'm surprised you'd never noticed!!
Oh yes, I had noticed. It's just that fame is short lived in this fast paced world.
Marc
Microsoft MVP, Visual C#
MyXaml
MyXaml Blog
|
|
|
|
|
I would like to see an AF that will support P2P. Any framework that supports P2P would need a few basic features.
1. AutoDiscovery. The ability to find others automatically.
2. A decentralized system. No central server. This creates a weak spot. Think of 6 degrees of seperation here.
3. The ability to exchange information among peers. This would simply be some protocol or defined method for exchanging data. The specifics of the data are not important at this layer. The applications built on top of it would interpret it.
4. Events. The ability of the upper application to register some callbacks into the API for events. Some possible events might be notification of a peer joining and leaving the network.
5. Ability to form a co-op. By this I mean you have a general pool. This is anybody running the application. Individuals running the same framework should be able to form private, invite only co-ops within the network. Sort of like the jocks and the geeks in high school. Except neither is aware of the other's existance.
6. Ability to penetrate firewalls.
7. Ability to configure how it communicates over the network. By this I mean being able to run over TCP or UDP and the port(s) used. If everybody built an app using the framework and they all used the same port(s) there could be some problems.
8. Resolution of conflicting apps. By this I mean if two completely different apps are built on to of the framework and somehow choose the same port(s) etc, they should be able to talk to each other and realize that they aren't the same app. So perhaps a signature header in the autodiscovery protocol that identifies the type of application uniquely.
As for ideas for usage of this framework. I don't have any specific ones in mind. However, some uses could be collaboration tools, file sharing, distributed network storage, fault tolerant systems.
Imaging building a database on top of a P2P platform. Now everybody shares the load. Each peer stores a small piece of the whole pie. Several peers share the same information (think RAID). This provides the ability for fault tolerance and greater storage as the number of peers increase. You also make it possible to serve information from peers that are local therefore localizing network traffic.
What do ya think? Have an feeling it won't be voted up based upon the latest ideas showing up. However I think my ideas have merit. The thing I like about it is that it is something relatively new and a chance to learn something new. It's not a complete recreate of the wheel either.
--
"The money power of the country will endeavor to prolong its rule by preying upon the prejudices of the people until all wealth is concentrated in a few hands and the Republic destroyed."
-- Abraham Lincoln
|
|
|
|
|
Yeah, this AF idea could just expand into infinity, and it looks like that's already started.
Maybe we should just limit it to ways of connecting normally used code rather than writing a bunch of utility classes that people could use. (i.e. Write a set of interfaces with default implementations for managing plug-ins, commands, toolbar buttons, menus, documents, views, etc. This way, people can write plug-ins that'll replace or extend the default implementations, as well as invent completely new additions that would still fit perfectly into the architecture. (As most things are now, a new utility class invented by someone else needs to be hooked into a program from code rather than a simple configuration file.)) Don't you just love those extended parenthetic statements?
John
"We want to be alone when we hear too many words and we feel alone when it has been a while since anyone has spoken to us." Paul David Tripp -- War of Words
|
|
|
|
|
I agree, it should probably be cut down to a small, flexible design with only a couple of the ideas we have put forward.
But what do you think are the best ideas, Marc? This is your project to lead.
Jason Henderson latest CPP news
"If you are going through hell, keep going." - Winston Churchill
|
|
|
|
|
Jason Henderson wrote:
it should probably be cut down to a small, flexible design with only a couple of the ideas we have put forward
We also have to remember that people are volunteering their own time, so it has to be fun, short, and engaging.
I don't know if this will be engaging to everyone, but the idea that's crystalizing for me, after reading all these posts, is a framework implemented in C# that provides for the near painless integration of scripts for the purpose of unit testing, regression testing, prototyping, and workflow specification/changes. The .NET framework really makes this possible with its Reflection, Type, and Activator namespaces/classes, allowing "remote control" of methods, properties, parameters, etc.
(Pardon the sounding board). I think this is doable, interesting, uses some fun technologies, and results in a really useful product.
Comments?
Marc
|
|
|
|
|
Sounds good!
It could be used as a built-in debugging/testing apparatus even after a production release.
Over the last couple of years, I've really been pushing for better error logging and application logging in our apps and it makes a world of difference. Adding scripting support would really help our QA team.
What about MACRO recording? Kind of like outputting to your script language for latter playback.
Jason Henderson latest CPP news
"If you are going through hell, keep going." - Winston Churchill
|
|
|
|
|
I've been toying with the idea of using C# or VB as the scripting language for macros/scripting, since the VB/C# compilers come with the .NET framework.
"Blessed are the peacemakers, for they shall be called sons of God." - Jesus
"You must be the change you wish to see in the world." - Mahatma Gandhi
|
|
|
|
|
Jason Henderson wrote:
Over the last couple of years, I've really been pushing for better error logging and application logging in our apps and it makes a world of difference. Adding scripting support would really help our QA team.
I was project lead many years ago on a project that was allocated 6 months of testing. The product was released after 3 months. Why? Because of instrumentation. Have you any idea how nice it was to look at event logs instead of asking QA "what did you do to make THAT happen?"???
Yes, you probably do!
Jason Henderson wrote:
What about MACRO recording?
Great idea!
Marc
Help! I'm an AI running around in someone's f*cked up universe simulator. Sensitivity and ethnic diversity means celebrating difference, not hiding from it. - Christian Graus Every line of code is a liability - Taka Muraoka Microsoft deliberately adds arbitrary layers of complexity to make it difficult to deliver Windows features on non-Windows platforms--Microsoft's "Halloween files"
|
|
|
|
|
Marc Clifton wrote:
Have you any idea how nice it was to look at event logs instead of asking QA "what did you do to make THAT happen?"???
Yes, you probably do!
Oh yeah.
Marc Clifton wrote:
Great idea!
thanks
Jason Henderson latest CPP news
"If you are going through hell, keep going." - Winston Churchill
|
|
|
|
|
If anything, I must admire the timing. I'm currently in the midst of designing, or trying to find design notes or methodologies for developing scriptable applications, while also allowing record and playback via the GUI. Sounds like what's being discussed is pretty much on the mark (no pun intended). I will point out that I have contacted Microsoft to get their concepts on the matter, since they've obviously implemented this once or twice. We'll see where that goes.
I'd like to see how things progress, and would be happy to contribute (I just can't believe there's no serious development environment for C# other than VS.Net - which I can't afford personally). Several thoughts:
I agree with having the Scripting Layer be one of the foundations of the Application Framework. Having this embedded and not as a plugin, I believe, would allow for other plugins to expose information to the scripting layer, thus allowing them to be part of that interaction. Furthermore, it will allow for record/playback IF, and probably ONLY IF there's a good definition of GUI to Actions, and Scripting to Actions. What I mean by this is that the GUI should have, as per your AAL, pretty much NO code in it other than execution of actions, which would be mimicked by the script. Thus, record & playback of data manipulation would be straigtforward. Of course, you always get into that whole deal about scripting GUI (which is a mess - opening/closing windows, selection, active window, search & replace, bla bla bla) - I'm happy to assume I don't really need that peice.
... will 2 cents do? I'm dry out of blood...
Yaron Golan
Yet Another Developer
|
|
|
|
|
YaronGolan wrote:
I just can't believe there's no serious development environment for C# other than VS.Net - which I can't afford personally
Have you seen SharpDevelop?[^]?
YaronGolan wrote:
Having this embedded and not as a plugin, I believe, would allow for other plugins to expose information to the scripting layer, thus allowing them to be part of that interaction.
Not to sound repetitive from my reply in your previous message, but take a look at the prototype.[^]
YaronGolan wrote:
and probably ONLY IF there's a good definition of GUI to Actions, and Scripting to Actions.
This is an interesting point that I haven't considered. My focus for the vision of this thing is that it is a mediator that has user defined workflow processes triggered by events or state change.
YaronGolan wrote:
Of course, you always get into that whole deal about scripting GUI (which is a mess
Exactly. Even in the AAL, it's not that easy. I've been adding direct GUI control and the issues of window control--opening and closing in particular--is a pain because of the way the messaging system works in MFC. For example, when closing a dialog, I have to add a message to resume script processing, terminate the current script processor, and release control back to MFC. Very annoying and prone to errors.
If you haven't joined already (and you're still interested), sign up for the CPPSF mailing list and send everyone a brief Bio. Here's the project kick-off email:
http://www.codeproject.com/useritems/CPPSF_DIARY.asp#xx524776xx[^]
Thanks for you interest, Yaron. I really like your ideas and thinking!
Marc
Help! I'm an AI running around in someone's f*cked up universe simulator. Sensitivity and ethnic diversity means celebrating difference, not hiding from it. - Christian Graus Every line of code is a liability - Taka Muraoka Microsoft deliberately adds arbitrary layers of complexity to make it difficult to deliver Windows features on non-Windows platforms--Microsoft's "Halloween files"
|
|
|
|
|
You know, I develop (too much, I think) code for server side components. The DAL is, IMHO, quite well (although not optimally) addressed by the .NET framework and several 3rd party tools out there.
The UI part is a well solved question these days, although a very time consuming part.
What still really requires lots of work is the BLL, and has small help from most frameworks, and all the components orchestration. There are deployment issues, too, that could be addressed by the idea I'll show you. I'll try to put it on words, but, without a diagram maybe it becomes hard to understand.
The BLL is composed of "components": I'm not caring yet about what's a physical implementation of a component, it could be a DLL, an EXE, a script (whether proprietary or not), a .NET class, or all of them.
Each component has a declared set of input and output data, and validation rules. Each component can be "plugged" (maybe visually, on an editor) on others depending whether the set of inputs and outputs are compatible or not.
Each connection has attributes that guide the execution flow, like the DTS designer for SQL Server, so components can be executed "on failure", "on commit", "on validation failed", "on ok", "queued", "in n-ways parallel" (reducing problems with multithreaded code). The components could be stored on repositories (obviously, suject to source code version control), and reused between several projects.
I think we could be really inovative creating something like this as an AF, just like event-driven code was several years ago, and some said "what? Do you mean I need to split my code in all those small event handling functions?". The same thing applies here: "what? Do you mean I need to split my business rules in all those data processing functions?"
The idea, here is the same behind Windows and event-driven UIs: you are not in control of the flow anymore, the system and the user are.
So, the AF would be this huge (actually, its code would be small) component orchestrator.
Kant wrote:
Actually she replied back to me "You shouldn't fix the bug. You should kill it"
|
|
|
|
|
Daniel Turini wrote:
What still really requires lots of work is the BLL
Exactly!
Daniel Turini wrote:
Each connection has attributes that guide the execution flow
Interesting idea.
Daniel Turini wrote:
So, the AF would be this huge (actually, its code would be small) component orchestrator.
Basically, that's where I think we're at. Nothing ships without an API nowadays, and usually the API is complex enough to be classified as a framework. What we need is an umbrella framework (I used that term in an earlier post somewhere too).
Stupid question, but it's because it's hard for me to shift mental gears--tell me how this is different from my AAL framework (yes, this is a major reference point for me, so it helps me to think in terms of that context. Whack me over the head if you get tired of hearing about it)? What areas are specialized?
A diagram would be great. Do you have the time to gen one up? I have Visio, or a JPG or GIF would be fine too.
And thanks for the post. I'm finding that there's more people than just little ol' me that is thinking along these lines. It's nice.
Marc
Help! I'm an AI running around in someone's f*cked up universe simulator. Sensitivity and ethnic diversity means celebrating difference, not hiding from it. - Christian Graus Every line of code is a liability - Taka Muraoka Microsoft deliberately adds arbitrary layers of complexity to make it difficult to deliver Windows features on non-Windows platforms--Microsoft's "Halloween files"
|
|
|
|
|
Marc Clifton wrote:
Stupid question, but it's because it's hard for me to shift mental gears--tell me how this is different from my AAL framework (yes, this is a major reference point for me, so it helps me to think in terms of that context. Whack me over the head if you get tired of hearing about it)? What areas are specialized?
Whack!
Basically, if I understood and remember it right, your AAL is a kind of data-centric, and with a "data hub" raising events that start moving the gears. This, in my point of view, is great, but has a really big impact as how applications are designed.
My design is process-centric, and can imply in much less impact, with most of the gains of AAL. Data is "merely" an input or an output of a process. The most similar diagram that I can imagine is a multi-layer perceptron (maybe because I work a lot with neural networks, I tend to design several things like NN). A process is this huge collection of very small and simple components, like hidden layers of the perceptron. It has an "input layer", where you feed it with some data, and an "output layer", where you can collect the resulting data.
There are other things I didn't mention, like "data adapters", which are components that can get data output by a component and convert it to make it suitable to another component (e.g., a Celsius-Fahrenheit conversor).
Marc Clifton wrote:
A diagram would be great. Do you have the time to gen one up? I have Visio, or a JPG or GIF would be fine too.
I'll do one when I get home. You know, I'm supposed to be working, right now
Kant wrote:
Actually she replied back to me "You shouldn't fix the bug. You should kill it"
|
|
|
|
|
Daniel Turini wrote:
Basically, if I understood and remember it right, your AAL is a kind of data-centric, and with a "data hub" raising events that start moving the gears. This, in my point of view, is great, but has a really big impact as how applications are designed.
That's what I don't like, also. Helpful, but not what I'm looking for.
Daniel, I'm interested to see your ideas , and I am working on a model of mine, as time permits. I think that together we can do much better than we could singly.
"Blessed are the peacemakers, for they shall be called sons of God." - Jesus
"You must be the change you wish to see in the world." - Mahatma Gandhi
|
|
|
|
|
jdunlap wrote:
That's what I don't like, also. Helpful, but not what I'm looking for.
Ack. The forest for the trees problem. It's only because I haven't gotten to the workflow manager, the script engine, etc. Process management has a big role (at least equal to data management) in the AAL universe.
Marc
Help! I'm an AI running around in someone's f*cked up universe simulator. Sensitivity and ethnic diversity means celebrating difference, not hiding from it. - Christian Graus Every line of code is a liability - Taka Muraoka Microsoft deliberately adds arbitrary layers of complexity to make it difficult to deliver Windows features on non-Windows platforms--Microsoft's "Halloween files"
|
|
|
|
|
Ah yes, I can see how this impression is arrived at. However, there's some big pieces that I haven't gotten to yet--the workflow manager/script engine, data access layer (yeah, I know!), etc. The plug-in architecture is essentially complete. However, you are correct also--it is more data-centric (the MFC version was really process centric, and it had some drawbacks). So I decided to tackle the problem from the other side.
However, to me, data is the key, because people get into so much trouble trying to manage it.
Marc
Help! I'm an AI running around in someone's f*cked up universe simulator. Sensitivity and ethnic diversity means celebrating difference, not hiding from it. - Christian Graus Every line of code is a liability - Taka Muraoka Microsoft deliberately adds arbitrary layers of complexity to make it difficult to deliver Windows features on non-Windows platforms--Microsoft's "Halloween files"
|
|
|
|
|
Marc Clifton wrote:
However, to me, data is the key, because people get into so much trouble trying to manage it.
We'll want to be sure to address data management, but not only that.
"Blessed are the peacemakers, for they shall be called sons of God." - Jesus
"You must be the change you wish to see in the world." - Mahatma Gandhi
|
|
|
|
|
|
vote for participation in AAL development here.
|
|
|
|
|
Vote for doing something new here.
|
|
|
|
|
To me, the idea of an application framework consists of:
a way to manage services - a service being a component in the application that performs a service for other components in an application (for instance, a property or resource manager, a file IO manager, etc.)
a way to manage addins and the extensions they provide - an addin being an external assembly/assembly group that extends the intrinsic functionality of the application
some basic services, such as:
property manager service - stores global properties
there would also be a standard interface and base class to automate the reading and writing of properties
messaging service - a system for outputting messages to the reader.
Any component can add its own "messenger" to the messenger collection. The messenger takes care of outputting the message to the user. In this way, we can abstract the message from its method of output. The message center routes the messages to where they should go - for instance, it could route log messages to a log file messenger, hints/tips to an MS Agent character messenger, input messages to a messagebox messenger, status messages to a status bar our output window, etc.
resource service - manages global resources
a standard model for automating commands
"Blessed are the peacemakers, for they shall be called sons of God." - Jesus
"You must be the change you wish to see in the world." - Mahatma Gandhi
|
|
|
|
|