PyWacketPyWacket|
Project /
ProjectProject.Project HistoryHide minor edits - Show changes to markup Deleted lines 55-103:
Lessons LearnedThe evolution of the project has been interesting. In the last two years, some of my ideas about this project have changed - progressed I hope. Using Python to the MaxMy understanding of Python technologies has also evolved over the last few years, but the basic idea for the project has also evolved. Keep it simple, do one thing at a time and do it well, never ever ever repeat yourself. Keep it as Pythonic as possible, use the built-in standard library modules ( like multiprocessing ! ) as much as possible. Simple Well-Designed GUI ApplicationsSimple, well-designed desktop applications functions can be very useful. A small host of Python applications ( the Exaile music player for example ) can provide of core for a 'run anywhere' desktop. There are also tools and techniques that meet many different integration needs without any Python coding or coding of any sort. For instance, X-Forwarding combined with Cygwin on Windows platforms can be extremely useful. A couple of relatively slow machines can split the graphics workload from the applications workload and produce roughly twice the throughput as a single machine. With X-Forwarding via Cygwin, an insecure Windows machine can hide behind a secure Linux machine, without the overhead of running a virtual machine. In fact, any overhead can be split over two less-than-state-of-the-art machines. Simple Well-Designed Console ApplicationsOverall, desktop GUI applications are a still part the project but not as much as they were from a Python perspective. A good console application can run on a Linux server and that's very good functionality to have for an integration platform. Decent web browser 'monitor type' applications are also valuable for Linux server-side functions. Some demos of Tornado websockets are also very impressive and powerful. Focus on Linux Server Integration, Simplify It !More important than code is the overall infra-structure and configuration management, servers, inter-process messaging, etc.. In addition to graphical desktops, GUI-free/Python-enriched servers are also within the project scope and promise to make the inner workings of servers much more visible and much easier to administer. The Three S's - Security, Security, Security.The projects above started from a general interest in Python, but more specifically and urgently as a result of the insecurity of PHP web applications on the old BBcom site ( soon to be an HTML-only site) . To make a long story short, the bad hackers beat the snot out of me. Maybe I will have better luck and more control over security running Python apps. Develop Concrete Usage ScenariosAnything is possible, anything is doable .... in theory. In practice, smaller is better. The cyberworld ( especially the Python cyberworld ) is littered with high-quality, but enormous application frameworks that may comprise many thousands of lines of code. They can accomplish a huge range of functions, almost anything you can imagine and some things you never thought of. Django is a good example, it's a very good framework and works well for big applications. But it seems to be that for desktop level apps, smaller frameworks do the best job accomplishing a specific task. So the upshot is keep requirements simple and under control. It has been said that one good question is worth more than any number of useless answers. Tight, focused usage scenarios help to nail down what actually needs to be done and prevent the 'scope creep' that plagues so many software applications. The Known UnknownNote that this is just an entry point into these projects - the schedule for the whole thing is pretty vague. For example, the timeline for the RuleForge has been repeatedly revised from period of several months to several years, a schedule slip of about 1000% ... so far. At 10 hours per week, it could take several years ( more! ) to build to a concrete inference engine application. Changed lines 62-63 from:
Using Python to the Maxto:
Using Python to the MaxChanged lines 67-68 from:
Simple Well-Designed GUI Applicationsto:
Simple Well-Designed GUI ApplicationsChanged lines 76-77 from:
Simple Well-Designed Console Applicationsto:
Simple Well-Designed Console ApplicationsChanged lines 81-82 from:
Focus on Linux Server Integration, Simplify It !to:
Focus on Linux Server Integration, Simplify It !Changed lines 86-87 from:
The Three S's - Security, Security, Security.to:
The Three S's - Security, Security, Security.Changed line 91 from:
Develop Concrete Usage Scenariosto:
Develop Concrete Usage ScenariosChanged lines 89-90 from:
Develop Usage Scenariosto:
Develop Concrete Usage ScenariosChanged lines 93-95 from:
The cyberworld ( especially the Python cyberworld ) is littered with high-quality, but enormous application frameworks that may comprise many thousands of lines of code. They can accomplish a huge range of functions, almost anything you can imagine and some things you never thought of. Django is a good example, it's a very good framework and works well for big applications. But it seems to be that for desktop level apps, smaller frameworks that do the best job accomplishing a specific task. It has been said that one good question is worth more than any number of useless answers. Tight, focused usage scenarios help to nail down what actually needs to be done and prevent the 'scope creep' that plagues so many software applications. to:
The cyberworld ( especially the Python cyberworld ) is littered with high-quality, but enormous application frameworks that may comprise many thousands of lines of code. They can accomplish a huge range of functions, almost anything you can imagine and some things you never thought of. Django is a good example, it's a very good framework and works well for big applications. But it seems to be that for desktop level apps, smaller frameworks do the best job accomplishing a specific task. So the upshot is keep requirements simple and under control. It has been said that one good question is worth more than any number of useless answers. Tight, focused usage scenarios help to nail down what actually needs to be done and prevent the 'scope creep' that plagues so many software applications. Changed line 93 from:
The cyberworld ( especially the Python cyberworld ) is littered with enormous application frameworks comprising many thousands of lines of code that can accomplish a huge range of functions, almost anything you can imagine and some things you never thought of. But it seems to be the smaller, more focused frameworks that do the best job accomplishing a specific task. to:
The cyberworld ( especially the Python cyberworld ) is littered with high-quality, but enormous application frameworks that may comprise many thousands of lines of code. They can accomplish a huge range of functions, almost anything you can imagine and some things you never thought of. Django is a good example, it's a very good framework and works well for big applications. But it seems to be that for desktop level apps, smaller frameworks that do the best job accomplishing a specific task. Changed line 102 from:
For instance, the timeline for the RuleForge has been repeatedly revised from period of several months to several years, a schedule slip of about 1000% ... so far. At 10 hours per week, it could take several years ( more! ) to build to a concrete application. to:
For example, the timeline for the RuleForge has been repeatedly revised from period of several months to several years, a schedule slip of about 1000% ... so far. At 10 hours per week, it could take several years ( more! ) to build to a concrete inference engine application. Changed lines 15-18 from:
to:
Changed lines 36-38 from:
to:
Changed lines 53-55 from:
The evolution of the project has been interesting. In the last two years, some of my ideas about this project have changed - progressed I hope. to:
The evolution of the project has been interesting. In the last two years, some of my ideas about this project have changed - progressed I hope. Using Python to the MaxMy understanding of Python technologies has also evolved over the last few years, but the basic idea for the project has also evolved. Keep it simple, do one thing at a time and do it well, never ever ever repeat yourself. Keep it as Pythonic as possible, use the built-in standard library modules ( like multiprocessing ! ) as much as possible. Changed lines 63-69 from:
Simple, well-designed desktop applications functions can be very useful. For instance, X-Forwarding combined with Cygwin on Windows platforms can be extremely useful and it meets many different integration needs without any Python coding or coding of any sort. A couple of relatively slow machines can split the graphics workload from the applications workload and produce roughly twice the throughput as a single machine. With X-Forwarding via Cygwin, an insecure Windows machine can hide behind a secure Linux machine, without the overhead of running a virtual machine. In fact, any overhead can be split over two less-than-state-of-the-art machines. A small host of Python applications ( the Exaile music player for example ) can provide of core for a 'run anywhere' desktop. to:
Simple, well-designed desktop applications functions can be very useful. A small host of Python applications ( the Exaile music player for example ) can provide of core for a 'run anywhere' desktop. There are also tools and techniques that meet many different integration needs without any Python coding or coding of any sort. For instance, X-Forwarding combined with Cygwin on Windows platforms can be extremely useful. A couple of relatively slow machines can split the graphics workload from the applications workload and produce roughly twice the throughput as a single machine. With X-Forwarding via Cygwin, an insecure Windows machine can hide behind a secure Linux machine, without the overhead of running a virtual machine. In fact, any overhead can be split over two less-than-state-of-the-art machines. Changed lines 72-77 from:
Overall, desktop GUI applications are a atill part the project but not as much as they were from a Python perspective. A good console application can run on a Linux server. That's very good functionality to have for an integration platform. Decent web browser 'monitor type' applications are also valuable for Linux server-side functions. Some demos of Tornado websockets are also very impressive and powerful. Using Python to the MaxMy understanding of Python technologies has also evolved over the last few years, but the basic idea for the project has also evolved. Keep it simple, do one thing at a time and do it well, never ever ever repeat yourself. Keep it as Pythonic as possible, use the built-in standard library modules ( like multiprocessing ! ) as much as possible. to:
Overall, desktop GUI applications are a still part the project but not as much as they were from a Python perspective. A good console application can run on a Linux server and that's very good functionality to have for an integration platform. Decent web browser 'monitor type' applications are also valuable for Linux server-side functions. Some demos of Tornado websockets are also very impressive and powerful. Changed line 62 from:
A small host of Python applications ( the Exaile music player for example ) can provide of core for a 'run anywhere' desktop. to:
A small host of Python applications ( the Exaile music player for example ) can provide of core for a 'run anywhere' desktop. Changed lines 1-2 from:
The purpose of PyWacket is 'weaving' desktop computers together, be they Windows, MacIntosh or Linux systems ( both client and server ). PyWacket started out as desktop integration and process management using Python GTK+ and Glade applications - it was highly experimental and took a few years ( part time ) to work through myriad combinations of programs packages to achieve a highly level of integration between Windows, Linux and also the Apple OSX. Note that OSX is nice to have, but I don't have a Mac so ... to:
The purpose of PyWacket is 'weaving' desktop computers together, be they Windows, MacIntosh or Linux systems ( both client and server ). PyWacket started out as desktop integration and process management using Python GTK+ and Glade applications - it was highly experimental and took a few years ( part time ) to work through myriad combinations of programs packages to achieve a highly level of integration between Windows, Linux and also the Apple OSX. This incarnation of PyWacket is focused on creating a semantic wiki application capable of supporting a fairly complex knowledge base and control panel for integrating desktop configurations. Changed lines 11-13 from:
to:
Changed lines 58-60 from:
Simple, well-designed desktop applications functions can be very useful. For instance, X-Forwarding combined with Cygwin on Windows platforms can be extremely useful and it meets many different integration needs without any Python coding or coding of any sort. A couple of relatively slow machines can split the graphics workload from the applications workload and produce almost twice the throughput as a single machine. With X-Forwarding via Cygwin, an insecure Windows machine can hide behind a secure Linux machine, without the overhead of running a virtual machine. In fact, any overhead can be split over two less-than-state-of-the-art machines. to:
Simple, well-designed desktop applications functions can be very useful. For instance, X-Forwarding combined with Cygwin on Windows platforms can be extremely useful and it meets many different integration needs without any Python coding or coding of any sort. A couple of relatively slow machines can split the graphics workload from the applications workload and produce roughly twice the throughput as a single machine. With X-Forwarding via Cygwin, an insecure Windows machine can hide behind a secure Linux machine, without the overhead of running a virtual machine. In fact, any overhead can be split over two less-than-state-of-the-art machines. A small host of Python applications ( the Exaile music player for example ) can provide of core for a 'run anywhere' desktop. Deleted lines 6-8:
Added lines 8-9:
Deleted lines 47-48:
Changed lines 52-53 from:
Using Simple Well-Designed GUI Applicationsto:
Simple Well-Designed GUI ApplicationsAdded line 59:
Added line 64:
Added line 69:
Added lines 79-88:
Develop Usage ScenariosAnything is possible, anything is doable .... in theory. In practice, smaller is better. The cyberworld ( especially the Python cyberworld ) is littered with enormous application frameworks comprising many thousands of lines of code that can accomplish a huge range of functions, almost anything you can imagine and some things you never thought of. But it seems to be the smaller, more focused frameworks that do the best job accomplishing a specific task. It has been said that one good question is worth more than any number of useless answers. Tight, focused usage scenarios help to nail down what actually needs to be done and prevent the 'scope creep' that plagues so many software applications. Deleted line 93:
Changed lines 3-22 from:
The evolution of the project has been interesting. In the last two years, some of my ideas about this project have changed - progressed I hope. Using Simple Well-Designed GUI ApplicationsSimple, well-designed desktop applications functions can be very useful. For instance, X-Forwarding combined with Cygwin on Windows platforms can be extremely useful and it meets many different integration needs without any Python coding or coding of any sort. A couple of relatively slow machines can split the graphics workload from the applications workload and produce almost twice the throughput as a single machine. With X-Forwarding via Cygwin, an insecure Windows machine can hide behind a secure Linux machine, without the overhead of running a virtual machine. In fact, any overhead can be split over two less-than-state-of-the-art machines. Simple Well-Designed Console ApplicationsOverall, desktop GUI applications are a atill part the project but not as much as they were from a Python perspective. A good console application can run on a Linux server. That's very good functionality to have for an integration platform. Decent web browser 'monitor type' applications are also valuable for Linux server-side functions. Some demos of Tornado websockets are also very impressive and powerful. Using Python to the MaxMy understanding of Python technologies has also evolved over the last few years, but the basic idea for the project has also evolved. Keep it simple, do one thing at a time and do it well, never ever ever repeat yourself. Keep it as Pythonic as possible, use the built-in standard library modules ( like multiprocessing ! ) as much as possible. Focus on Linux Server Integration, Simplify It !More important than code is the overall infra-structure and configuration management, servers, inter-process messaging, etc.. In addition to graphical desktops, GUI-free/Python-enriched servers are also within the project scope and promise to make the inner workings of servers much more visible and much easier to administer. to:
OverviewMajor projects ( or aspects of the overall project ) include:
A basic diagram of the parts:
Changed lines 39-42 from:
Future ContentEventually, the basic subjects of site will include: to:
Eventually, the basic subjects of the site will include: Changed lines 46-58 from:
Major projects ( or aspects of the overall project ) will also include:
A basic diagram of the parts: to:
Changed lines 49-56 from:
to:
Lessons LearnedThe evolution of the project has been interesting. In the last two years, some of my ideas about this project have changed - progressed I hope. Using Simple Well-Designed GUI ApplicationsSimple, well-designed desktop applications functions can be very useful. For instance, X-Forwarding combined with Cygwin on Windows platforms can be extremely useful and it meets many different integration needs without any Python coding or coding of any sort. A couple of relatively slow machines can split the graphics workload from the applications workload and produce almost twice the throughput as a single machine. With X-Forwarding via Cygwin, an insecure Windows machine can hide behind a secure Linux machine, without the overhead of running a virtual machine. In fact, any overhead can be split over two less-than-state-of-the-art machines. Simple Well-Designed Console ApplicationsOverall, desktop GUI applications are a atill part the project but not as much as they were from a Python perspective. A good console application can run on a Linux server. That's very good functionality to have for an integration platform. Decent web browser 'monitor type' applications are also valuable for Linux server-side functions. Some demos of Tornado websockets are also very impressive and powerful. Using Python to the MaxMy understanding of Python technologies has also evolved over the last few years, but the basic idea for the project has also evolved. Keep it simple, do one thing at a time and do it well, never ever ever repeat yourself. Keep it as Pythonic as possible, use the built-in standard library modules ( like multiprocessing ! ) as much as possible. Focus on Linux Server Integration, Simplify It !More important than code is the overall infra-structure and configuration management, servers, inter-process messaging, etc.. In addition to graphical desktops, GUI-free/Python-enriched servers are also within the project scope and promise to make the inner workings of servers much more visible and much easier to administer. Changed line 59 from:
to:
Changed lines 11-13 from:
Overall, desktop GUI applications are a part the project but not as much as they were from a Python perspective. A good console application can run on a Linux server. That's very good functionality to have for an integration platform. Decent web browser 'monitor type' applications are also valuable for Linux server-side functions. Some demos of Tornado websockets are also very impressive and powerful. to:
Simple Well-Designed Console ApplicationsOverall, desktop GUI applications are a atill part the project but not as much as they were from a Python perspective. A good console application can run on a Linux server. That's very good functionality to have for an integration platform. Decent web browser 'monitor type' applications are also valuable for Linux server-side functions. Some demos of Tornado websockets are also very impressive and powerful. Changed line 7 from:
Simple, well-designed desktop applications functions can be very useful. For instance, X-Forwarding combined with https://www.cygwin.com/ Cygwin on Windows platforms can be extremely useful and it meets many different integration needs without any Python coding or coding of any sort. A couple of relatively slow machines can split the graphics workload from the applications workload and produce almost twice the throughput as a single machine. to:
Simple, well-designed desktop applications functions can be very useful. For instance, X-Forwarding combined with Cygwin on Windows platforms can be extremely useful and it meets many different integration needs without any Python coding or coding of any sort. A couple of relatively slow machines can split the graphics workload from the applications workload and produce almost twice the throughput as a single machine. Changed lines 32-33 from:
Future Contentto:
Future ContentChanged lines 59-61 from:
The Three S'sSecurity, Security, Security. to:
The Three S's - Security, Security, Security.Added lines 5-6:
Using Simple Well-Designed GUI ApplicationsChanged lines 11-14 from:
Overall, desktop GUI applications are a part the project but not as much as they were from a Python perspective. A good console application can run on a Linux server. That's very good functionality to have for an integration platform. Decent web browser 'monitor type' applications are also valuable for Linux server-side functions. Some demos of Tornado websockets are also very impressive and powerful. My understanding of Python technologies has also evolved over the last few years, but the basic idea for the project has also evolved. Keep it simple, do one thing at a time and do it well, never ever ever repeat yourself. Keep it as Pythonic as possible, use the built-in standard library modules ( like multiprocessing ! ) as much as possible. to:
Overall, desktop GUI applications are a part the project but not as much as they were from a Python perspective. A good console application can run on a Linux server. That's very good functionality to have for an integration platform. Decent web browser 'monitor type' applications are also valuable for Linux server-side functions. Some demos of Tornado websockets are also very impressive and powerful. Using Python to the MaxMy understanding of Python technologies has also evolved over the last few years, but the basic idea for the project has also evolved. Keep it simple, do one thing at a time and do it well, never ever ever repeat yourself. Keep it as Pythonic as possible, use the built-in standard library modules ( like multiprocessing ! ) as much as possible. Focus on Linux Server Integration, Simplify It !Added lines 32-33:
Future ContentChanged lines 59-63 from:
These projects started from a general interest in Python, but more specifically as a result of the insecurity of PHP web applications on the old BBcom site ( soon to be an HTML-only site) . To make a long story short, the bad hackers beat the snot out of me. Maybe I will have better luck and more control over security running Python apps. to:
The Three S'sSecurity, Security, Security. The projects above started from a general interest in Python, but more specifically and urgently as a result of the insecurity of PHP web applications on the old BBcom site ( soon to be an HTML-only site) . To make a long story short, the bad hackers beat the snot out of me. Maybe I will have better luck and more control over security running Python apps. Changed lines 1-5 from:
The purpose of PyWacket is 'weaving' desktop computers together, be they Windows, MacIntosh or Linux systems ( both client and server ). PyWacket started out as desktop integration and process management using Python GTK+ and Glade applications - it was highly experimental and took a few years ( part time ) to work through myriad combinations of programs packages to achieve a highly level of integration between Windows and Linux. It's been interesting. Simple functions such as X-Forwarding are particularly useful and meet many integration needs without any Python coding or coding of any sort. A couple of relatively slow machines can split the graphics workload from the applications workload and produce almost twice the throughput as a single machine. Desktop GUI applications are still central but not as much as they were from a Python perspective. My understanding of Python technologies has evolved over the last few years, but the basic idea for the project has also evolved. More important tahn code is the overall infra-structure and configuration management, servers, inter-process messaging, etc.. In addition to graphical desktops, GUI-free/Python-enriched servers are also within the project scope and promise to make the inner workings of servers much more visible and much easier to administer. to:
The purpose of PyWacket is 'weaving' desktop computers together, be they Windows, MacIntosh or Linux systems ( both client and server ). PyWacket started out as desktop integration and process management using Python GTK+ and Glade applications - it was highly experimental and took a few years ( part time ) to work through myriad combinations of programs packages to achieve a highly level of integration between Windows, Linux and also the Apple OSX. Note that OSX is nice to have, but I don't have a Mac so ... The evolution of the project has been interesting. In the last two years, some of my ideas about this project have changed - progressed I hope. Simple, well-designed desktop applications functions can be very useful. For instance, X-Forwarding combined with https://www.cygwin.com/ Cygwin on Windows platforms can be extremely useful and it meets many different integration needs without any Python coding or coding of any sort. A couple of relatively slow machines can split the graphics workload from the applications workload and produce almost twice the throughput as a single machine. With X-Forwarding via Cygwin, an insecure Windows machine can hide behind a secure Linux machine, without the overhead of running a virtual machine. In fact, any overhead can be split over two less-than-state-of-the-art machines. Overall, desktop GUI applications are a part the project but not as much as they were from a Python perspective. A good console application can run on a Linux server. That's very good functionality to have for an integration platform. Decent web browser 'monitor type' applications are also valuable for Linux server-side functions. Some demos of Tornado websockets are also very impressive and powerful. My understanding of Python technologies has also evolved over the last few years, but the basic idea for the project has also evolved. Keep it simple, do one thing at a time and do it well, never ever ever repeat yourself. Keep it as Pythonic as possible, use the built-in standard library modules ( like multiprocessing ! ) as much as possible. More important than code is the overall infra-structure and configuration management, servers, inter-process messaging, etc.. In addition to graphical desktops, GUI-free/Python-enriched servers are also within the project scope and promise to make the inner workings of servers much more visible and much easier to administer. Changed line 1 from:
The purpose of PyWacket is 'weaving' desktop computers together, be they Windows, MacIntosh or Linux systems. PyWacket started out as desktop integration and process management using Python GTK+ and Glade applications - it was highly experimental and took a few years ( part time ) to work through myriad combinations of programs packages to achieve a highly level of integration between Windows and Linux. to:
The purpose of PyWacket is 'weaving' desktop computers together, be they Windows, MacIntosh or Linux systems ( both client and server ). PyWacket started out as desktop integration and process management using Python GTK+ and Glade applications - it was highly experimental and took a few years ( part time ) to work through myriad combinations of programs packages to achieve a highly level of integration between Windows and Linux. Changed lines 5-6 from:
My understanding of Python technologies has evolved over the last few years, but the basic idea for the project has also evolved. - more important is the overall infrastructure such configuration management, servers, messaging, etc.. In addition to graphical desktops, GUI-free/Python-enriched servers are also within the project scope and promise to make the inner workings of servers much more visible and much easier to administer. to:
My understanding of Python technologies has evolved over the last few years, but the basic idea for the project has also evolved. More important tahn code is the overall infra-structure and configuration management, servers, inter-process messaging, etc.. In addition to graphical desktops, GUI-free/Python-enriched servers are also within the project scope and promise to make the inner workings of servers much more visible and much easier to administer. Changed line 47 from:
For instance, the timeline for the RuleForge was repeatedly revised from several months to several years, a schedule slip of about 1000% ... so far. At 10 hours per week, it could take several years ( more! ) to get to concrete application. to:
For instance, the timeline for the RuleForge has been repeatedly revised from period of several months to several years, a schedule slip of about 1000% ... so far. At 10 hours per week, it could take several years ( more! ) to build to a concrete application. Changed line 43 from:
These projects started from a general interest in Python, but more specifically as a result of the insecurity of PHP web applications on the old BBcom site. To make a long story short, the bad hackers beat the snot out of me. Maybe I will have better luck and more control over security running Python apps. to:
These projects started from a general interest in Python, but more specifically as a result of the insecurity of PHP web applications on the old BBcom site ( soon to be an HTML-only site) . To make a long story short, the bad hackers beat the snot out of me. Maybe I will have better luck and more control over security running Python apps. Deleted lines 42-43:
Note that this is just an entry point into these projects. The timeline for the RuleForge has been revised from several months to several years. The PyWacket project has consumed maybe 10 hours per week for the last several years to complete. Added lines 44-48:
Note that this is just an entry point into these projects - the schedule for the whole thing is pretty vague. For instance, the timeline for the RuleForge was repeatedly revised from several months to several years, a schedule slip of about 1000% ... so far. At 10 hours per week, it could take several years ( more! ) to get to concrete application. Added lines 35-41:
A basic diagram of the parts:
Changed lines 45-46 from:
(:pagelist group=Project list=normal fmt=#title:) to:
(:pagelist group=Project list=normal fmt=#title:) Changed lines 1-5 from:
The purpose of PyWacket is 'weaving desktop computers together, be they Windows, MacIntosh or Linux systems. PyWacket started out as desktop integration and process management using Python GTK+ and Glade applications - it was highly experimental and took a few years ( part time ) to work through the myriad combinations packages . My understanding of Python technologies has evolved over the last few years, but the basic idea for the project has also evolved. Desktop GUI applications are not as central as they were - more important is the overall infrastructure such configuration management, servers, messaging, etc.. In addition to graphical desktops, GUI-free, Python-enriched servers are also within the project scope. The basic subjects of the PyWacket development site be: to:
The purpose of PyWacket is 'weaving' desktop computers together, be they Windows, MacIntosh or Linux systems. PyWacket started out as desktop integration and process management using Python GTK+ and Glade applications - it was highly experimental and took a few years ( part time ) to work through myriad combinations of programs packages to achieve a highly level of integration between Windows and Linux. It's been interesting. Simple functions such as X-Forwarding are particularly useful and meet many integration needs without any Python coding or coding of any sort. A couple of relatively slow machines can split the graphics workload from the applications workload and produce almost twice the throughput as a single machine. Desktop GUI applications are still central but not as much as they were from a Python perspective. My understanding of Python technologies has evolved over the last few years, but the basic idea for the project has also evolved. - more important is the overall infrastructure such configuration management, servers, messaging, etc.. In addition to graphical desktops, GUI-free/Python-enriched servers are also within the project scope and promise to make the inner workings of servers much more visible and much easier to administer. In the long run, basic subjects of the PyWacket development site will be: Changed lines 1-4 from:
The purpose of PyWacket is 'weaving desktop computers together, be they Windows, MacIntosh or Linux systems. PyWacket started out as desktop integration and process management using Twisted, wxPython and GTK+ applications - it was highly experimental. The idea for the project has evolved over the last few years. The GUI is not as important as the overall infrastructure, configuration management, messaging, making it easier to 'weave systems together'. In addition to graphical desktops, GUI-free servers are also within the project scope. to:
The purpose of PyWacket is 'weaving desktop computers together, be they Windows, MacIntosh or Linux systems. PyWacket started out as desktop integration and process management using Python GTK+ and Glade applications - it was highly experimental and took a few years ( part time ) to work through the myriad combinations packages . My understanding of Python technologies has evolved over the last few years, but the basic idea for the project has also evolved. Desktop GUI applications are not as central as they were - more important is the overall infrastructure such configuration management, servers, messaging, etc.. In addition to graphical desktops, GUI-free, Python-enriched servers are also within the project scope. The basic subjects of the PyWacket development site be:
Changed lines 13-19 from:
The basic subjects of the PyWacket development site be:
to:
Added lines 35-36:
These projects started from a general interest in Python, but more specifically as a result of the insecurity of PHP web applications on the old BBcom site. To make a long story short, the bad hackers beat the snot out of me. Maybe I will have better luck and more control over security running Python apps. Changed line 3 from:
It has evolved over the last few years. In addition to desktops, GUI-free servers are also within the project scope. to:
The idea for the project has evolved over the last few years. The GUI is not as important as the overall infrastructure, configuration management, messaging, making it easier to 'weave systems together'. In addition to graphical desktops, GUI-free servers are also within the project scope. Changed lines 26-28 from:
to:
Changed lines 30-35 from:
Trac Plug-ins - useful plug-ins, some customized, supporting the developed RuleForge CMS, and maybe some semantic web extensions.
Python Components - useful parts and fragments of Python code.
Note that this is just an entry point into these projects. Each project deserves and will eventually have a Trac wiki of its own. The timeline for the RuleForge is fairly short, maybe 2-4 months ( once I figure out what I need to do and start developing, late 2011 ? ). The others such as PyWacket may take several years to complete. to:
Note that this is just an entry point into these projects. The timeline for the RuleForge has been revised from several months to several years. The PyWacket project has consumed maybe 10 hours per week for the last several years to complete. Changed lines 1-2 from:
The purpose of PyWacket is 'weaving desktop computers together, be they Windows, MacIntosh or Linux systems. to:
The purpose of PyWacket is 'weaving desktop computers together, be they Windows, MacIntosh or Linux systems. PyWacket started out as desktop integration and process management using Twisted, wxPython and GTK+ applications - it was highly experimental. It has evolved over the last few years. In addition to desktops, GUI-free servers are also within the project scope. Major components include:
Added lines 22-35:
Major projects ( or aspects of the overall project ) will also include:
Trac Plug-ins - useful plug-ins, some customized, supporting the developed RuleForge CMS, and maybe some semantic web extensions.
Python Components - useful parts and fragments of Python code.
Note that this is just an entry point into these projects. Each project deserves and will eventually have a Trac wiki of its own. The timeline for the RuleForge is fairly short, maybe 2-4 months ( once I figure out what I need to do and start developing, late 2011 ? ). The others such as PyWacket may take several years to complete. Changed lines 5-7 from:
Server and Peer-to-Peer Apps for Knowledge-Based systems
Desktop Integration and Client-Server Apps
to:
Changed lines 10-13 from:
Rule Engines and Rule-Based Systems
Business Rules
Semantic Web
Knowledge Engineering and Knowledge-Based Apps
to:
Changed lines 1-3 from:
Parts of the project Some sort of query in here ?? to:
The purpose of PyWacket is 'weaving desktop computers together, be they Windows, MacIntosh or Linux systems. The basic subjects of the PyWacket development site be: Server and Peer-to-Peer Apps for Knowledge-Based systems
Desktop Integration and Client-Server Apps
Eventually, the basic subjects of site will include: Rule Engines and Rule-Based Systems
Business Rules
Semantic Web
Knowledge Engineering and Knowledge-Based Apps
Project PagesChanged lines 3-5 from:
Some sort of query in here ?? to:
Some sort of query in here ?? (:pagelist group=Project list=normal fmt=#title:) |