PyWacket

One overall caveat is that all binary dependencies can be satisfied on three different types of operation systems, four types including Linux server ( or six type if one includes Android and iPad systems ).  In some cases, it might be OK because the application will only need run on Linux, such as the [[http://icecast.org/ | icecast streaming media server]], which I would never under any circumstances run on Windows.  Or, major binary dependencies can be satisfied in one big chunk, like [[https://www.cygwin.com/ | Cywin for Windows}}.  However, in general, custom binaries are out of the question for this project.

One overall caveat is that all binary dependencies can be satisfied on three different types of operation systems, four types including Linux server ( or six type if one includes Android and iPad systems ).  In some cases, it might be OK because the application will only need run on Linux, such as the [[http://icecast.org/ | icecast streaming media server]], which I would never under any circumstances run on Windows.  But, in general, custom binaries are more or less out of the question.

* PyWacket Peer-to-Peers - workstations running "localhost" clients/servers on a private network.  Examples include Twisted/PyGTK clients with Twisted daemons, maybe lighttpd, no Apache, possibly running in conjunction with a [[http://bazaar.canonical.com/en/ | Bazaar]] repository  ).

A caveat is that all binary dependencies can be satisfied on three different types of operation systems, four types including Linux server ( or six type if one includes Android and iPad systems ).  So PyWacket custom binaries are more or less out of the question.

* PyWacket Peer-to-Peers - workstations running Twisted and  wxPython and "localhost" clients/servers on a private network ( as a twisted daemon, no Apache, may or may not have a subversion repository ).

At this point, the focus of PyWacket has shifted to developing a Python semantic wiki similar to Semantic Mediawiki which will power the Semantastic site.

A caveat is that all binary dependencies can be satisfied on three different types of operation systems, four types including Linux server ( or six type if one includes Android and iPad systems ).  So Pywacket custom binaries are more or less out of the question.

It's import to develop a concrete set of usage scenarios.  It helps to define what is important and limit 'scope creep' that seems to be innate in every software project.

It's import to develop a concrete set of usage scenarios

An example would be integrating email clients across different machines, particularly those pesky "email sent" messages strewn across a dozen machines/operating systems/email apps. It should work for selected email clients on both Linux and Windows, and perhaps the Mac as a nice to have. Another big plus is the ability to run on netbook computers ( Windows/Linux ) as a sort of desktop for small python applications as well a email integration.

Other examples include shared/synchronized links and documents, versioning of documents, common system management and security tools, and dozens of other potential desktop needs.

There two sets of Pywacket usage scenarios: one for the desktop, the other for a semantic/knowledge wiki application ( that is, semantastic ).  The two usages overlap in that knowledge about desktop configuration and local network services can be representing in the semwiki.

A caveat is that all binary dependencies can be satisfied on three different types of operation systems, four types including Linux server ( or six type if one includes Android and iApple systems ).  So binaries are more or less out of the question.

A caveat is that all binary dependencies can be satisfied on three different types of operation systems, four types including Linux server ( or six type if one includes Android and iApple systems ).  So binaries are more or less out of the question.

The PyWacket project is intended to integrate common desktop functions between different OS installations running on the same or different machines using primarily Python components.  The idea is to 'weave' different machine together seamlessly.

The PyWacket application is intended to integrate common desktop functions between different OS installations running on the same or different machines using primarily Python components ( in so far as binary dependencies can be satisfied ).

In one version, there would be a common server to replicate data across several machines: in another version, there would be peer-to-peer synchronization. Probably implementing both is the correct answer, first the peer-to-peer framework and then the server framework .

* PyWacket Peer-to-Peers - workstations running Twisted and  wxPython and "localhost" clients/servers on a private network ( as a twisted daemon, no Apache, may or may not have a subversion repository ).