PyWacketPyWacket|
Project /
ProjectProject.Project HistoryHide minor edits - Show changes to output Deleted lines 55-103:
!!!!Lessons Learned 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 Max 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. !!!Simple Well-Designed GUI Applications Simple, well-designed desktop applications functions can be very useful. A small host of Python applications ( the [[http://www.exaile.org/ | 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 [[https://www.cygwin.com/ | 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 Applications 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 [[http://www.tornadoweb.org/en/branch2.1/websocket.html | 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 - ''S''ecurity, ''S''ecurity, ''S''ecurity. 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 [[http://billbreitmayer.com | 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 Scenarios Anything 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. [[https://www.djangoproject.com/ | 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 Unknown Note 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:
to:
!!!Using Python to the Max Changed lines 67-68 from:
to:
!!!Simple Well-Designed GUI Applications Changed lines 76-77 from:
to:
!!!Simple Well-Designed Console Applications Changed lines 81-82 from:
to:
!!!Focus on Linux Server Integration, Simplify It ! Changed lines 86-87 from:
to:
!!!The Three S's - ''S''ecurity, ''S''ecurity, ''S''ecurity. Changed line 91 from:
to:
!!!Develop Concrete Usage Scenarios Changed lines 89-90 from:
!!!!Develop Usage Scenarios to:
!!!!Develop Concrete Usage Scenarios Changed 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. 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. [[https://www.djangoproject.com/ | 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 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 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:
* Python Components of various sorts - useful parts and fragments of Python code. to:
Changed lines 36-38 from:
* Message Queue system, using the RabbitMQ, Java and Python multiprocessing modules to:
* Message Queue system, using the RabbitMQ, Java and Python multiprocessing modules. * Messaging Protocols, XMPP and AMQP and associated servers, implemented in Python and Java. * A large collection Python line command tools, scripts, and configuration management utilities. Pexpect is a good example. * Some sort of plugin architecture. Something like the original Trac-based RuleForge site ( now defunct ) and maybe some semantic web extensions. * Python Components of various sorts - useful parts and fragments of Python code. 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 Max 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. Changed lines 63-69 from:
Simple, well-designed desktop applications functions can be very useful. With X-Forwarding via Cygwin, an insecure Windows machine A small host of Python applications ( the [[http://www.exaile.org/ | 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 [[http://www.exaile.org/ | 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 [[https://www.cygwin.com/ | 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 !!!!Using Python to the Max 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 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 [[http://www.tornadoweb.org/en/branch2.1/websocket.html | Tornado websockets]] are also very impressive and powerful. Changed line 62 from:
A small host of Python applications ( the to:
A small host of Python applications ( the [[http://www.exaile.org/ | 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 ). 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:
* [[Project/Semantastic | Semantastic]] - semantic wiki, * [[Project/RuleForge | RuleForge]] - extended content structuring and semantic tagging to:
* [[Project/Semantastic | Semantastic]] - a semantic wiki, based on Semantic MediaWiki functionality ported to Python. * [[Project/RuleForge | RuleForge]] - extended content structuring and semantic tagging ( RDF ) capabilities and a simple inference and workflow engine. This should 'circle back' to the desktop integration aspect of the Pywacket project. Changed lines 58-60 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 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 [[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 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:
* [[Project/RuleForge | RuleForge]] - extended content structuring and semantic tagging capabilities. Maybe a simple inference engine. Added lines 8-9:
* [[Project/RuleForge | RuleForge]] - extended content structuring and semantic tagging capabilities. Maybe a simple inference engine. Deleted lines 47-48:
Changed lines 52-53 from:
!!!! to:
!!!!Simple Well-Designed GUI Applications Added line 59:
Added line 64:
Added line 69:
Added lines 79-88:
!!!!Develop Usage Scenarios Anything 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 27-28 from:
to:
------------------- Changed line 48 from:
to:
Changed lines 3-22 from:
Simple, well With X !!!!Simple Well-Designed Console Applications 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 [[http://www.tornadoweb.org/en/branch2.1/websocket.html | Tornado websockets]] are also very impressive and powerful. !!!!Using Python to the Max 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. !!!!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:
!!!!Overview Major projects ( or aspects of the overall project ) include: * [[Project/RuleForge | RuleForge]] - extended content structuring and semantic tagging capabilities. Maybe a simple inference engine. * [[Project/Semantastic | Semantastic]] - semantic wiki, probably based on Semantic MediaWiki, unless a can port the functionality to Python. * Some sort of plugin architecture. Something like the original Trac-based RuleForge site ( now defunct ) and maybe some semantic web extensions. * Python Components of various sorts - useful parts and fragments of Python code. A basic diagram of the parts: ------------------- || bgcolor=lightyellow ||Base Integration Architecture ||supporting => ||Semantic Wiki Application ||supporting => ||Rule-Based Implementation || || || || || || || ||Pywacket || ||Semantasic || ||RuleForge || || || || || || || ||Python ( and other ) frameworks || ||Python-based Semantic MediaWiki clone || ||A wiki/knowledge base about rule engines etc.|| Changed lines 39-42 from:
Eventually, the basic subjects of site will include: to:
Eventually, the basic subjects of the site will include: Changed lines 46-58 from:
* [[Project/RuleForge | RuleForge]] - extended content structuring and semantic tagging capabilities. Maybe a simple inference engine. * [[Project/Semantastic | Semantastic]] - semantic wiki, probably based on Semantic MediaWiki, unless a can port the functionality to Python. * Some sort of plugin architecture. Something like the original Trac-based RuleForge site ( now defunct ) and maybe some semantic web extensions. * Python Components of various sorts - useful parts and fragments of Python code. A basic diagram of the parts: to:
Changed lines 49-56 from:
||Base Integration Architecture ||supporting => ||Semantic Wiki Application ||supporting => ||Rule-Based Implementation || || || || || || || ||Pywacket || ||Semantasic || ||RuleForge || || || || || || || ||Python ( and other ) frameworks || ||Python-based Semantic MediaWiki clone || ||A wiki/knowledge base about rule engines etc.|| to:
!!!!Lessons Learned 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 Applications 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. !!!!Simple Well-Designed Console Applications 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 [[http://www.tornadoweb.org/en/branch2.1/websocket.html | Tornado websockets]] are also very impressive and powerful. !!!!Using Python to the Max 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. !!!!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:
||Base Integration Architecture ||supporting => ||Semantic Wiki Application ||supporting => || to:
||Base Integration Architecture ||supporting => ||Semantic Wiki Application ||supporting => ||Rule-Based Implementation || Added lines 56-57:
------------------- Added lines 62-63:
------------------- Changed lines 11-13 from:
to:
!!!!Simple Well-Designed Console Applications 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 [[http://www.tornadoweb.org/en/branch2.1/websocket.html | 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 [[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. Changed line 63 from:
!!!The Known Unknown to:
!!!!The Known Unknown Changed lines 32-33 from:
!!!Future Content to:
!!!!Future Content Changed lines 59-61 from:
!!!!The Three S's ''S''ecurity, ''S''ecurity, ''S''ecurity. to:
!!!!The Three S's - ''S''ecurity, ''S''ecurity, ''S''ecurity. Added lines 5-6:
!!!!Using Simple Well-Designed GUI Applications Changed 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 [[http://www.tornadoweb.org/en/branch2.1/websocket.html | Tornado websockets]] are also very impressive and powerful. My understanding of Python technologies has also evolved over the last few years, but 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 [[http://www.tornadoweb.org/en/branch2.1/websocket.html | Tornado websockets]] are also very impressive and powerful. !!!!Using Python to the Max 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. !!!!Focus on Linux Server Integration, Simplify It ! Added lines 32-33:
!!!Future Content Changed lines 59-63 from:
to:
!!!!The Three S's ''S''ecurity, ''S''ecurity, ''S''ecurity. 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 [[http://billbreitmayer.com | 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 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 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 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 [[http://www.tornadoweb.org/en/branch2.1/websocket.html | 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. 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 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 [[http://billbreitmayer.com | 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 [[http://billbreitmayer.com | 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:
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: || bgcolor=lightyellow ||Base Integration Architecture ||supporting => ||Semantic Wiki Application ||supporting => ||Specific Implementation || ||Pywacket || ||Semantasic || ||RuleForge || ||Python ( and other ) frameworks || ||Python-based Semantic MediaWiki clone || ||A wiki/knowledge base about rule engines etc.|| 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 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 basic subjects of the PyWacket development site 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 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: * Server and Peer-to-Peer Apps for Knowledge-Based systems * Desktop Integration and Client-Server Apps Changed lines 13-19 from:
* Messaging Protocols, XMPP and AMQP The basic subjects of the PyWacket development site be: * Server * Desktop Integration and Client-Server Apps to:
* Messaging Protocols, XMPP and AMQP and associated servers, implemented in Python and Java * A large collection Python line command tools, scripts, and configuration management utilities. Pexpect is a good example. 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 [[http://billbreitmayer.com | 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:
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:
* RuleForge * Semantastic to:
* [[Project/RuleForge | RuleForge]] - extended content structuring and semantic tagging capabilities. Maybe a simple inference engine. * [[Project/Semantastic | Semantastic]] - semantic wiki, probably based on Semantic MediaWiki, unless a can port the functionality to Python. Changed lines 30-35 from:
Note that this is just an entry point into these projects. to:
* Some sort of plugin architecture. Something like the original Trac-based RuleForge site ( now defunct ) and maybe some semantic web extensions. * Python Components of various sorts - useful parts and fragments of Python code. 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: * Message Queue system, using the RabbitMQ, Java and Python multiprocessing modules * Messaging Protocols, XMPP and AMQP * Various Python line command tools and Added lines 22-35:
Major projects ( or aspects of the overall project ) will also include: * RuleForge - extended content structuring and semantic tagging capabilities for Trac. Maybe a simple inference engine. * Semantastic - semantic wiki, probably based on MediaWiki. 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:
to:
* Server and Peer-to-Peer Apps for Knowledge-Based systems * Desktop Integration and Client-Server Apps Changed lines 10-13 from:
Business Rules Semantic Web to:
* Rule Engines and Rule-Based Systems * Business Rules * Semantic Web * Knowledge Engineering and Knowledge-Based Apps Changed lines 1-3 from:
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 Pages Changed lines 3-5 from:
Some sort of query in here ?? to:
Some sort of query in here ?? (:pagelist group=Project list=normal fmt=#title:) |