Hello fellow UFP'ers. A warm welcome for our new cousins the OpenCard folk. That's what this letter is about. We now have two collaborations that, while quite similar and in fact complementary, are nevertheless distinct. DIFFERENCES : 1. UFP'ers are scripting-oriented while OpenCard'ers are programming-oriented. 2. UFP'ers use HyperTalk and AppleScript while OpenCard'ers will probably use C++. 3. UFP'ers are focused on developing RAD tools with HyperCard, while OpenCard'ers are focused on improving HyperCard itself. SIMILARITIES : 1. Shared vision of the value of HyperCard as-is and the mythical 3.0 version. 2. Shared knowledge and experience of HyperCard. 3. OpenCard will be scriptable in OpenTalk. The latter will be a compatible superset of the current HyperTalk we all know and love. OpenTalk will support AppleScript and Externals, just as HyperCard does today. COMPLEMENTARY : 1. UFP'ers are focused on developing RAD tools with HyperCard, while OpenCard'ers are focused on improving HyperCard itself. UFP scripters could request from the OpenCard team new features that would simplify their scripting tasks, for example. 2. OpenCard'ers will be able to focus on low-level generic stuff, like infrastructure, language, and so on, leaving application-level functionality and examples to the UFP team. STRATEGIC DECISIONS : 1. Both collaborations have their own mailing list. I believe that this will remain the case, but cross-linkages can and should be made between the two. Each of these groups will thus be able to co-develop for better final results. 2. Should we have two distinct Web-Site-Infrastructures, or just one augmented one ? 3. Make our Web-Site-Infrastructure(s) look and feel like HyperCard ? 4. In any case, use an infrastructure similar to the one the UFP currently uses. An infrasstructure composed of a section for each dimension of our collective work that : a) displays current content of that section, as an index b) displays current content of that section, as a hierarchy of elements c) displays current content of that section, on a card-by-card basis (soon) d) allows one to add an element to that section (newCard) e) allows one to duplicate, modify or delete an element to that section (soon) f) allows one to search through the section's database (soon) g) allows one to customize the presentation of the generated pages above (soon) An example to illustrate the above. The UFP Handlers Library. A HyperCard stack (database) of all of our handlers that contains many meta-data-items to exhaustively describe each handler. The interface consists of web pages and forms that allow members to (a) view the handlers as an index ; (b) view the handlers library as an hierarchy (categories) of handlers ; (c) each handler can be viewed and downloaded separately ; (d) a new handler can be added ; (e) the rest is not quite ready but also quite do-able. This dynamically-generated web site is produced in real-time by our handlers library stack via a CGI ( a HC standalone! ). And so on for each and every dimension of our collaboration, such as Threads, Digests, Guidelines, Goals, Tasks, ... 5. In this regard, it would be advisable for the OpenCard'ers to establish what sections will be needed to create our HyperCard-compatible application, such as Names for our "clone", Languages-debate, Goals, Tasks, SourceCode, and so on. It would be nice to break-down the entire development process into a coherent set of related stacks such as I have described here. POWER TO THE PEOPLE Alain Farmer UFP mailto:[EMAIL PROTECTED] OpenCard mailto:[EMAIL PROTECTED] Personal mailto:[EMAIL PROTECTED]
