PyWacketPyWacket|
Project /
ComponentsOn this page... (hide) 1. Basic RequirementComponents consist mainly of Python modules and possibly some binaries. Installation must be very easy for Windows, either via Python easy_install or a Windows installer for binaries ( no compiler in other words ). For Linux, installed components might come directly from the OS repository or via easy_install from the PyPi? repository. 2. What is a Software Component ?The answer is more difficult than one might expect. There are several uses of the word "component" for different things, in other words, there are multiple definitions. An individual software component is a software package, a web service, a web resource, or a module that encapsulates a set of related functions (or data).
All system processes are placed into separate components so that all of the data and functions inside each component are semantically related (just as with the contents of classes). Because of this principle, it is often said that components are modular and cohesive.
With regard to system-wide co-ordination, components communicate with each other via interfaces. When a component offers services to the rest of the system, it adopts a provided interface that specifies the services that other components can utilize, and how they can do so. This interface can be seen as a signature of the component - the client does not need to know about the inner workings of the component (implementation) in order to make use of it. This principle results in components referred to as encapsulated. The UML illustrations within this article represent provided interfaces by a lollipop-symbol attached to the outer edge of the component.
Wikipedia's definition is about as good as it gets. However, the definition is entirely from a software perspective. Perhaps a better rephrasing might be " ... that encapsulates a set of related functions (or knowledge)". Defining 'knowledge-based' component architecture is a key ingredient to this project. 3. Ubiquitous Desktop ApplicationsCommon desktop applications between Windows, Linux and perhaps the Mac is a large and growing suite of GTK+ desktop applications such Geany and Seamonkey, with Python bindings/wrappers and Twisted, for either basic process control or more fine-grained control via API ( if available ). To make development of an integrated process manager a bit easier, some sort of rule-based workflow engine is envisioned, but details remain sketchy. Trac may be another common component across the three operating systems, running as tracd and providing a sort of system configurator knowledge base and control panel application. The Windows installation of Trac has a special .exe version that makes installation of Python dependencies much easier for the average Windows user. A question is how to run PyWacket peer-to-peer on Windows with Subversion or some sort of quick-and-easy version control. The Bazaar version control package may be the answer. The standalone package contains all necessary dependencies, including its own Python 2.5. For details, see the slightly out-of-date page Windows Installer. Another possible component is Mercurial, also see http://en.wikipedia.org/wiki/Mercurial. Both provide additional distributed repository management functions that may more useful for the peer-to-peer version of PyWacket than Subversion. Other potentially ubiquitous components are:
Zim Wiki is a nice little Python desktop wiki with HTML publishing capabilities, among many other excellent Python desktop applications. It's an excellent example of how small quick Python apps can help power an integrated desktop. Small efficient Python apps ( with a few compiled apps and a few Java heavy hitters ) could become a 'familiar spirit' on the Windows/Linux/Macintosh desktop. 4. DatabaseDatabase technology is a very big part of PyWacket and of application integration in general. There are very few really heavy database apps outside of the corporate environment ( say 100 tables, 200 relationships ). The most ubiquitous database capable of driving light-weight, non-industrial applications is ... tah dah ... SQLite!. I have heard many moans and groans at this point. OMG, SQLite, how un-cool !!! Using recent software versions on modern hardware, a SQLite database can support anything from millions of ( short ) rows to a total DB size of several 100 megabytes ( for blob storage ). That's a lot of data by any standard outside of the corporate environment. Don't ask for a 1000 transactions per second, but that's not what I'm asking - maybe a hundred per second max, during DB synchronizations. SQLite is also part of the Python Standard Library, so it's always runnable everywhere, a key requirement. Also note that one of the best SQLite managers is a plugin for FireFox/Mozilla that also runs as XUL. That alone makes SQLite necessary. There might be need for applications that only use MySQL databases, but there is no reason not to downsize to SQLite for deployment across the integration environment. 5. DB Conversions and SQL AlchemySQL Alchemy deserves a section of its own. It's so good that it's a good reason to use Python, even if you didn't plan on it. The downside is that it is fairly heavy-weight, by Python standards. The overriding benefit is 'quick and easy' DB conversions, at least as quick and easy as DB conversions are capable of being. Flexible data storage and freedom from 'data jail' is a central part of the project, and is one of the central challenges for evolving any application. 6. To Do:Aside from developing the semwiki, tasks include:
|