From dev-return-33145-apmail-harmony-dev-archive=harmony.apache.org@harmony.apache.org Tue Apr 01 07:14:48 2008 Return-Path: Delivered-To: apmail-harmony-dev-archive@www.apache.org Received: (qmail 21582 invoked from network); 1 Apr 2008 07:14:48 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 1 Apr 2008 07:14:48 -0000 Received: (qmail 84133 invoked by uid 500); 1 Apr 2008 07:14:38 -0000 Delivered-To: apmail-harmony-dev-archive@harmony.apache.org Received: (qmail 84106 invoked by uid 500); 1 Apr 2008 07:14:38 -0000 Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@harmony.apache.org Delivered-To: mailing list dev@harmony.apache.org Received: (qmail 84097 invoked by uid 99); 1 Apr 2008 07:14:38 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 01 Apr 2008 00:14:38 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of t.p.ellison@gmail.com designates 209.85.128.187 as permitted sender) Received: from [209.85.128.187] (HELO fk-out-0910.google.com) (209.85.128.187) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 01 Apr 2008 07:13:56 +0000 Received: by fk-out-0910.google.com with SMTP id 18so3195528fks.4 for ; Tue, 01 Apr 2008 00:14:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:subject:x-enigmail-version:content-type:content-transfer-encoding; bh=+xDQgppRVTDv0zbFyEcvi3Bf8q5/CeB6hkTb79FX0+I=; b=iH70mkKk+TX3uVwWTGLZ/z2IwXZv6nwb3TWbZNgGR/Yux+cPzz8cHNCIGcLgWT0IAuDC6iQXcMa/w3Qa6+oxjYxmNydXoWooAqSmDWtohEJ0+WmALiouoEbm8+SoGAskBL3KFAHFaSt9I0ztSv8ibXYHHrhSpIvxX/zlXbvIWl4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:from:user-agent:mime-version:to:subject:x-enigmail-version:content-type:content-transfer-encoding; b=c7LQj/AaNxRL5LgRg/Rt7O34ScnjpaL1lU118lLGmVqW7tteVrMvZHqNWXXLbuj09sWH6wHYLSOVNBnZjqXdcT9CsEMtYW0fYEf6ZpUDfEO3UUmG/Ho4sYmRfzY/B5vtTsS/8zzHJkmfo+S8OSCSejZOge35OqL4cUyw19rj0Gs= Received: by 10.78.193.5 with SMTP id q5mr24209494huf.59.1207034046525; Tue, 01 Apr 2008 00:14:06 -0700 (PDT) Received: from ?192.168.0.5? ( [86.111.176.100]) by mx.google.com with ESMTPS id 1sm6291847nfv.3.2008.04.01.00.14.04 (version=SSLv3 cipher=RC4-MD5); Tue, 01 Apr 2008 00:14:05 -0700 (PDT) Message-ID: <47F1E050.5070404@gmail.com> Date: Tue, 01 Apr 2008 08:12:16 +0100 From: Tim Ellison User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: dev@harmony.apache.org Subject: [general] Proposal for "first-order obvious logic" project X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org There are a number of interesting student projects being proposed at the moment, and I'd like to add another one for everyone's consideration. It struck me this morning that since we have virtually got the entire platform working well, the remaining pieces could be deduced pretty well by simply describing the expected behaviour using the first-order 'obvious logic' principle. Using this principle we would simply write rules for the missing pieces, and implement an inference engine to evaluate these rules to complete the functionality. While the rules can be written in any language, I'd suggest a good candidate would be the new 'actor participation rules intermediate language 1', and evaluate them using the Java obvious knowledge engine. As an example of the rules we would need: *drag and drop support* Just implement drag. After all, once you are dragging something the only option you have is to drop it. That would be an obvious rule. *rich text format support* Just implement poor text support and invest in compounding instruments code. After a few years the compounding effect will make the text increasing richer. *not implemented exception* Obviously the user's application doesn't want to see this exception. Rather than throw the exception instrospect the stack and just return an object that will pass the application's validation checks instead. I'm unwilling to mentor the project after today, but if anyone else wants to pick up the 'first-order obvious logic' (FOOL) project, writing code in 'actor participation rule intermediate language 1' (APRIL1) for the 'Java obvious knowledge engine' (JOKE) -- then I'd be facinated to see how well it works! For more information see http://tinyurl.com/395w9a Regards, Tim