At 11:37 PM 12/30/99 +0200, you wrote:
Hi, Jason!
"JC" == Jason Cunliffe writes:
JC> Hello 1. I want to be able to email dtml directly to some zopesites and JC> have them accept my email, parse the headers/message body so that DMTL JC> autmoatically will be uploaded, and/or overwritten, all without any JC> need to manually ever go near a web browser.
JC> 2. To be able to send email to make various 'calls' to the site..
1&2 look rather easy to implement:
Something like procmail to take email and run script on it. That script would parse email, take the body and either put it as dtml code or use as xml-rpc call or do something other
Good. Can you think of a way to make the set up and installation of this basic mechanism as simple as possible?
JC> 3. To have a bunch of Zopesites tuned to a special zopista newsgroup. JC> Posting to the newsgroup would allow timestamped threaded data/messages JC> to be parsed in correct order.
Sorry, don't get that. Can you explain further?
OK... 1. generate a 'zope_radio' newsgroup or family of newsgroups designed to carry several types of messages.. 2. The zope_radio news posts contain: data in-line, data as attachments, DTML, logs, and also human-admin-user text traffic [comments etc] 3. The news post meta-types are designated either by a simple header grammar to allow fast parsing and/or segregated by related newsgroup: for example news://zoperadio.human, zoperadio.data, zoperadio.dtml, zoperadio.fs etc.. 4. All participating zope sites have a zope_radio Python External Method or Product which embeds nntplib and other Internet goodies, with a DTML wrapper to make useful high level calls for common functions as easy as possible ( perhaps more like REBOL [www.rebol.com] which parses the parameters and is smart about picking protocol and defaults ) 5. Since nntp newsgroup posts are threaded at the client end, the participating zope sites can be 'tuned' in several ways: - 'zoperadio' news post can be directed using url-path style headers.. those sites which don't have the corresponding path could ignore the message or take some other not_invented_here_action to enable reception.. The channel metaphor of radio send/ receive would thus be married to the web-object-path idea of acquisition. Let's suppose all participating zoperadio sites have a basic folder structure such as: yoursite.com/zoperadio/dtml ../data ../human /subscribe etc. - The minimum default might be to subscribe to zoperadio via a dtml button.. this would send a post to zoperadio telling it what the /zoperadio path structure and methods were. Zoperadio could then reply to this path structure, calling the methods available or send others to generate a richer site... 6. Once 'tuned' sites could use the nntp threading mechanism to sniff out the relevant posts very quickly using minimal bandwidth. Threaded news clients only download the data _after_ the headers have been selected. The installed zoperadio product could send auto-status replies from local sites back to the zoperadio newsgroup[s]. In this way the thread at zoperadio.stats could be parsed and visualized for getting powerful overview of zope site activity. 7. Humans and DTML methods with the relevant permissions could rapidly configure and post data to zope sites using the zoperadio newsgroups. One real advantage I see to using this nntp-zope hybrid approach is that there are many information transactions which should not be taking up people's time or server time. There is also a benefit I believe in using a well-known protocol to do what it does well - serve just-in time data to the widest possible platform. It can be handled and parsed by some many tools and has an intrinsic threading message threading capability which could be of great service by matching the zope-path context structure. Apart from the core nntp Zope Product/ExternalMethod, I think this scheme would not need to modify zope itself further. The new added value would be from using it in a different adaptive networked paradigm at multiple sites using well known and global tool which is one of the bedrock foundation of the Internet itself. Also storing the state sequence of a zope site without needing to transfer or backup all the data in the ZODB.. metazope-lite if you like ;-) The use of nntp to reflect aspect of zope sites could also spawn other non-web applications to be used and developed. This is more in-line with the demand now for 'internet appliances' and small wireless devices. These mobiles could post to the zoperadio thus creating a very effective data infrastructure bridge for input/output/feedback/rerouting. 8. The mechanism proposed here could allow zope sites to be partly cloned or sections of them to be routed and matched. For example if there are sections of site A which I want to use at site B, then I could use the zoperadio to send the structure only along with urls and keys. Site B could use the sections of site A by using this 'thin DTML' strategy. The zoperadio could send it the minimal path and virtual DTML without actually needing to load and install the DTML or data itself in the ZODB. Users at site B could be accessing site A pages and DTML within site B, by virtue of a special acquisition path. for example: http://siteB.com/zoperadio/virtual/siteA/myremotefolder/myremote_DTMLmethod Effectively this would route the siteB Client to siteA. The zoperadio could thus change the virtual DTML very quickly across many sites. One obvious benefit would be ability to use more media-heavy DTML without max-ing the 2Gb limit. 9. Time stamping inherent in news posts would allow messages to be threaded and thus affect the acquisition behavior. Also time series data could be handled in an effective way. The dynamics of zope web site use could be extended in new ways. Not just pages which are more adaptive to authoring and personal use but whole sites which change to use... I hope this makes some sense. - Jason __________________________________________________________________________ Jason CUNLIFFE = NOMADICS.(Interactive Art and Technology).Design Director