Internet communications engine.
|
View:
New views
7 Messages
—
Rating Filter:
Alert me
|
 |
Internet communications engine.
by mehri
::
Rate this Message:
Hi,
If you don't know what this email is about please catch up on the arch comm mailing list: http://list.alicebot.org/pipermail/alicebot-archcomm/2006-October/thread.html This discussion has been moved to this mailing list since it does not directly have to do with the arch comm and we want to open this discussion to a wider audience and include everyone's input. ---- Hey Noel, I think I got far ahead of myself in my enthusiasm this morning. I really don't want ICE (Internet Communications Engine http://www.zeroc.com/ice.html) to be a neutral specification mechansim. Rather it's just one of several technologies to allow network communications. As a matter of fact I really don't want any specific IDL (interface description language http://en.wikipedia.org/wiki/Interface_description_language) to do that. At the end of this email I'll explain what I think would be two important documents among us interpreter writers to actually write for each others benefit. Let me explain first though what I am doing with RebeccaAIML right now in development (beta release due in a month or two) and perhaps that'll help others understand how I'm slowly but surely opening the architecture to allow other AIML technologies to use it which will ultimately enable me to integrate other AIML technologies (such as programd) as well as non AIML technologies ;-) with it (such as possibly other non AIML bot implementations). I put the document discussing more of the network'ed ICE in RebeccaAIML here: http://rebecca-aiml.sourceforge.net/talkAboutDesign1.htm So, after reading that above document you should see that I'm moving more towards integration with other programming languages, other AIML interpreters either through RPC if they're servers or directly integrating them through interfaces. Making RebeccaAIML a kind of super SDK. But those ideas could easily be pulled out into one integration super bot and discussed here. What I would like to talk about creating documents to help developers would be: * class interfaces for each programming language. * IDL's for each RPC that's currently in use by AIML interpreters. Yea it's a tall order but I said make it a double! :-) I think in all honesty if we were to hash these two out we could get integration of several open source AIML bots together ourselves. Which would mean that development of gui tools would work across the board with different interperters. Interpreter new comers would be more than welcome. If they read the above documents and wanted to they could create adapters to their bots and they too would be able to use the various prewritten tools such as AIML test case drivers, admin tools etc... Noel said: -- In the purest sense, the interface to an AIML interpreter is just some kind of String getResponse(String). But as all of us know who work on real-world AIML interpreters that are intended for use in multiple contexts, there are so many additional concerns that always need to be handled that it makes sense to have some guidance from a spec about these, too. -- How about model the interfaces after Java Collection. For example, the top most interface you'd have to implement woul be just "String getResponse(String)". Another that inherits from that adds more operations but is more specific to a type of interperter. This would allow you to write tools where if that's all you need -- just the getResponse(String) it would work with most plugin'ed bots. A good example would be if I had written a lot of tools and suddenly wanted them to work w/ pandorabots and the language I wrote it in was C#. I just write XML-RPC specific to pandora bot to the C# interface and boom I'm done. Latter someone else writes one to Java and boom now all your other Java tools you wrote to work with different bots now works w/ XML-RPC and pandora. ----- Original Message ---- From: Noel Bush <noel@...> I think it is great to define a standard interface to an AIML interpreter. Of course, what you're considering expands the scope of "AIML interpreter" somewhat, to include things like loading/reloading AIML sets, setting/getting predicates externally, configuration, and so forth. In the purest sense, the interface to an AIML interpreter is just some kind of String getResponse(String). But as all of us know who work on real-world AIML interpreters that are intended for use in multiple contexts, there are so many additional concerns that always need to be handled that it makes sense to have some guidance from a spec about these, too. It seems somewhat analogous to the aims of the DOM specification, where you want to formally describe a set of common operations that are performed with XML documents. In this case, you want to formally describe a set of common operations that are performed with AIML interpreters. A discussion about this may also draw attention to some potentially interesting questions, such as the degree to which the matching algorithm needs to be part of the AIML spec (i.e., is the trie that is built by many AIML interpreters really the only way to specify/implement the functional requirements of the matching algorithm?). It might also be possible to offer some standardization about handling multiple bots, removing categories, and more. My question is, to what extent would ICE serve as a neutral specification mechanism? Like AIML, it's under the GPL, which is great, but what are its serious competitors? Does it have a chance of being widely adopted, or is it likely to remain associated with this particular company and cause open standards folks to shy away from it? If I understand right from a quick glance at the docs, it looks like the "Slice language" is essentially a C++ library, or something like that. I suppose that would mean that there are a lot of tools around already that can do interesting things with it, like produce other forms of documentation. To what extent does a Slice/ICE specification need to be supplemented with prose? Is it expressively limited or tortured in some way by the basis in C++? The AIML schema, for instance, while able to capture virtually everything about the syntax of AIML, has no way of explaining how AIML is to be processed, so it's necessary to keep a separate specification that defines functionality. It might be sensible to remove all the syntax specification from the AIML spec, and just include the schema, leaving only what cannot be covered by the schema in the spec document itself. But ideally, in the case of AIML as well as in the case of the AIML interpreter interface description, you would like to see everything in one form. An actual implementation is not such a great reference, as it generally includes too many distractions not pertinent to the domain (but here there's more and more along the lines of AOP/injection that can help in uncluttering things). Basically you want as near as you can get to an actual implementation without including anything that is platform- or application- specific. All could be a lot of fun to discuss. Noel _______________________________________________ This is the alicebot-general mailing list Reply to alicebot-general@... Unsubscribe and change preferences at http://list.alicebot.org/mailman/listinfo/alicebot-general Learn netiquette at http://www.dtcc.edu/cs/rfc1855.html Learn to read at http://www.literacy.org/ |
|
|
Re: Internet communications engine.
by Gary Dubuque
::
Rate this Message:
Hi,
Thanks for letting me know the ArchComm was revived. A few years ago I attempted to participate, but sadly have to say that I didn't contribute much. I never meant to leave the committee, but some how I got lost in the years of inactivity. Its nice to know there is a place to discuss possibilities for the architecture and language again. The ICE idea is cool (cold?) Is this something like what Robbie Gardner did to have multiple bots to chat? Anyway, when you get the standard interface, I can adjust ProgramN (AIMLpad) to both swap in interchangeable interpreters (and script to them) and to expose its built-in one hopefully including scripting and some aspects of its expert system engine. These last two things (script and expert) may be more difficult because they are event driven instead of post/response. Thanks, Gary Dubuque, revisiting the default pattern's opportunity to assist in "filling in the blanks" in creating AIML -----Original Message----- From: alicebot-general-bounces@... [mailto:alicebot-general-bounces@...]On Behalf Of mehri Sent: Wednesday, October 18, 2006 11:21 PM To: alicebot-general@... Subject: [alicebot-general] Internet communications engine. Hi, If you don't know what this email is about please catch up on the arch comm mailing list: http://list.alicebot.org/pipermail/alicebot-archcomm/2006-October/thread.htm l This discussion has been moved to this mailing list since it does not directly have to do with the arch comm and we want to open this discussion to a wider audience and include everyone's input. ---- Hey Noel, I think I got far ahead of myself in my enthusiasm this morning. I really don't want ICE (Internet Communications Engine http://www.zeroc.com/ice.html) to be a neutral specification mechansim. Rather it's just one of several technologies to allow network communications. As a matter of fact I really don't want any specific IDL (interface description language http://en.wikipedia.org/wiki/Interface_description_language) to do that. At the end of this email I'll explain what I think would be two important documents among us interpreter writers to actually write for each others benefit. Let me explain first though what I am doing with RebeccaAIML right now in development (beta release due in a month or two) and perhaps that'll help others understand how I'm slowly but surely opening the architecture to allow other AIML technologies to use it which will ultimately enable me to integrate other AIML technologies (such as programd) as well as non AIML technologies ;-) with it (such as possibly other non AIML bot implementations). I put the document discussing more of the network'ed ICE in RebeccaAIML here: http://rebecca-aiml.sourceforge.net/talkAboutDesign1.htm So, after reading that above document you should see that I'm moving more towards integration with other programming languages, other AIML interpreters either through RPC if they're servers or directly integrating them through interfaces. Making RebeccaAIML a kind of super SDK. But those ideas could easily be pulled out into one integration super bot and discussed here. What I would like to talk about creating documents to help developers would be: * class interfaces for each programming language. * IDL's for each RPC that's currently in use by AIML interpreters. Yea it's a tall order but I said make it a double! :-) I think in all honesty if we were to hash these two out we could get integration of several open source AIML bots together ourselves. Which would mean that development of gui tools would work across the board with different interperters. Interpreter new comers would be more than welcome. If they read the above documents and wanted to they could create adapters to their bots and they too would be able to use the various prewritten tools such as AIML test case drivers, admin tools etc... Noel said: -- In the purest sense, the interface to an AIML interpreter is just some kind of String getResponse(String). But as all of us know who work on real-world AIML interpreters that are intended for use in multiple contexts, there are so many additional concerns that always need to be handled that it makes sense to have some guidance from a spec about these, too. -- How about model the interfaces after Java Collection. For example, the top most interface you'd have to implement woul be just "String getResponse(String)". Another that inherits from that adds more operations but is more specific to a type of interperter. This would allow you to write tools where if that's all you need -- just the getResponse(String) it would work with most plugin'ed bots. A good example would be if I had written a lot of tools and suddenly wanted them to work w/ pandorabots and the language I wrote it in was C#. I just write XML-RPC specific to pandora bot to the C# interface and boom I'm done. Latter someone else writes one to Java and boom now all your other Java tools you wrote to work with different bots now works w/ XML-RPC and pandora. ----- Original Message ---- From: Noel Bush <noel@...> I think it is great to define a standard interface to an AIML interpreter. Of course, what you're considering expands the scope of "AIML interpreter" somewhat, to include things like loading/reloading AIML sets, setting/getting predicates externally, configuration, and so forth. In the purest sense, the interface to an AIML interpreter is just some kind of String getResponse(String). But as all of us know who work on real-world AIML interpreters that are intended for use in multiple contexts, there are so many additional concerns that always need to be handled that it makes sense to have some guidance from a spec about these, too. It seems somewhat analogous to the aims of the DOM specification, where you want to formally describe a set of common operations that are performed with XML documents. In this case, you want to formally describe a set of common operations that are performed with AIML interpreters. A discussion about this may also draw attention to some potentially interesting questions, such as the degree to which the matching algorithm needs to be part of the AIML spec (i.e., is the trie that is built by many AIML interpreters really the only way to specify/implement the functional requirements of the matching algorithm?). It might also be possible to offer some standardization about handling multiple bots, removing categories, and more. My question is, to what extent would ICE serve as a neutral specification mechanism? Like AIML, it's under the GPL, which is great, but what are its serious competitors? Does it have a chance of being widely adopted, or is it likely to remain associated with this particular company and cause open standards folks to shy away from it? If I understand right from a quick glance at the docs, it looks like the "Slice language" is essentially a C++ library, or something like that. I suppose that would mean that there are a lot of tools around already that can do interesting things with it, like produce other forms of documentation. To what extent does a Slice/ICE specification need to be supplemented with prose? Is it expressively limited or tortured in some way by the basis in C++? The AIML schema, for instance, while able to capture virtually everything about the syntax of AIML, has no way of explaining how AIML is to be processed, so it's necessary to keep a separate specification that defines functionality. It might be sensible to remove all the syntax specification from the AIML spec, and just include the schema, leaving only what cannot be covered by the schema in the spec document itself. But ideally, in the case of AIML as well as in the case of the AIML interpreter interface description, you would like to see everything in one form. An actual implementation is not such a great reference, as it generally includes too many distractions not pertinent to the domain (but here there's more and more along the lines of AOP/injection that can help in uncluttering things). Basically you want as near as you can get to an actual implementation without including anything that is platform- or application- specific. All could be a lot of fun to discuss. Noel _______________________________________________ This is the alicebot-general mailing list Reply to alicebot-general@... Unsubscribe and change preferences at http://list.alicebot.org/mailman/listinfo/alicebot-general Learn netiquette at http://www.dtcc.edu/cs/rfc1855.html Learn to read at http://www.literacy.org/ _______________________________________________ This is the alicebot-general mailing list Reply to alicebot-general@... Unsubscribe and change preferences at http://list.alicebot.org/mailman/listinfo/alicebot-general Learn netiquette at http://www.dtcc.edu/cs/rfc1855.html Learn to read at http://www.literacy.org/ |
|
|
|
|
|
Re: Internet communications engine.
by Gary Dubuque
::
Rate this Message:
Hi again,
Like yours, it is written in C++ (and C). It does not exactly have public interfaces since it is a stand-alone editor, but I did once put an OCX wrapper around it. It does include a small web server for testing purposes. Using its scripting language you can call out to XMLRPC (used for ConceptNet) and ip addresses (used for OpenCyc) and other internet sites (both gets and posts). Like you, I tried to reference to Program D, but I didn't quite get everything exactly right (namely namespaces in the AIML). It used to process Program D's targeting log, but I haven't tried it with the latest version. Currently I'm putting the regular expressions in to be similar to Program D (not exactly since I included two levels of substitution in the normalization - regular expressions before the sentence splitting and simple text replacement after.) Some simple extensions AIMLpad adds to AIML: <condition name="pred" notvalue="xxx"> to succeed when not matched - this is extended to the <li> stuff too. <get name="aiml-predicate-name" default="value" /> to overcome the incomplete specifications <replaceall key="match text" subst="value"> thanks to Kino Coursey for this goodie And I'm considering the possibility of <srai that="value"> to redefine the "that" part as well as rest of pattern Standard AIML v1.01 is handled too (as well as some more interesting extensions for us experimenters). BTW, the notvalue in conditions can be used like <condition name="pred" notvalue="*"> to get the answer to the problem created by <condition name="pred" value="">. Also it is extended to do: <condition name="pred1"> <li name="pred2">... to match predicate pred1 to predicate pred2 You can find it on SourceForge or at www.aimlpad.com Thanks, Gary Dubuque, always a <condition> with no matches returns an empty string! -----Original Message----- From: alicebot-general-bounces@... [mailto:alicebot-general-bounces@...]On Behalf Of mehri Sent: Thursday, October 19, 2006 10:51 PM To: Alicebot and AIML General Discussion Subject: Re: [alicebot-general] Internet communications engine. Hi Robert. I don't think I was around for Robbie's work? Do you happen to have any pointers to it? As for the interfaces I'll defintely keep you in the loop. Once I start marching full steam towards the interfaces the more interpreters I can work with and understand the better I can get a feel for what would make good interfaces. Currently what programming language(s) is ProgramN written in? Does it have any public interfaces for client side programming? Does it have any network communicatons -- if so what's the protocol(s)? ----- Original Message ---- From: Gary Dubuque <gdubuque@...> To: Alicebot and AIML General Discussion <alicebot-general@...> Sent: Thursday, October 19, 2006 11:22:50 PM Subject: Re: [alicebot-general] Internet communications engine. Hi, Thanks for letting me know the ArchComm was revived. A few years ago I attempted to participate, but sadly have to say that I didn't contribute much. I never meant to leave the committee, but some how I got lost in the years of inactivity. Its nice to know there is a place to discuss possibilities for the architecture and language again. The ICE idea is cool (cold?) Is this something like what Robbie Gardner did to have multiple bots to chat? Anyway, when you get the standard interface, I can adjust ProgramN (AIMLpad) to both swap in interchangeable interpreters (and script to them) and to expose its built-in one hopefully including scripting and some aspects of its expert system engine. These last two things (script and expert) may be more difficult because they are event driven instead of post/response. Thanks, Gary Dubuque, revisiting the default pattern's opportunity to assist in "filling in the blanks" in creating AIML -----Original Message----- From: alicebot-general-bounces@... [mailto:alicebot-general-bounces@...]On Behalf Of mehri Sent: Wednesday, October 18, 2006 11:21 PM To: alicebot-general@... Subject: [alicebot-general] Internet communications engine. Hi, If you don't know what this email is about please catch up on the arch comm mailing list: http://list.alicebot.org/pipermail/alicebot-archcomm/2006-October/thread.htm l This discussion has been moved to this mailing list since it does not directly have to do with the arch comm and we want to open this discussion to a wider audience and include everyone's input. ---- Hey Noel, I think I got far ahead of myself in my enthusiasm this morning. I really don't want ICE (Internet Communications Engine http://www.zeroc.com/ice.html) to be a neutral specification mechansim. Rather it's just one of several technologies to allow network communications. As a matter of fact I really don't want any specific IDL (interface description language http://en.wikipedia.org/wiki/Interface_description_language) to do that. At the end of this email I'll explain what I think would be two important documents among us interpreter writers to actually write for each others benefit. Let me explain first though what I am doing with RebeccaAIML right now in development (beta release due in a month or two) and perhaps that'll help others understand how I'm slowly but surely opening the architecture to allow other AIML technologies to use it which will ultimately enable me to integrate other AIML technologies (such as programd) as well as non AIML technologies ;-) with it (such as possibly other non AIML bot implementations). I put the document discussing more of the network'ed ICE in RebeccaAIML here: http://rebecca-aiml.sourceforge.net/talkAboutDesign1.htm So, after reading that above document you should see that I'm moving more towards integration with other programming languages, other AIML interpreters either through RPC if they're servers or directly integrating them through interfaces. Making RebeccaAIML a kind of super SDK. But those ideas could easily be pulled out into one integration super bot and discussed here. What I would like to talk about creating documents to help developers would be: * class interfaces for each programming language. * IDL's for each RPC that's currently in use by AIML interpreters. Yea it's a tall order but I said make it a double! :-) I think in all honesty if we were to hash these two out we could get integration of several open source AIML bots together ourselves. Which would mean that development of gui tools would work across the board with different interperters. Interpreter new comers would be more than welcome. If they read the above documents and wanted to they could create adapters to their bots and they too would be able to use the various prewritten tools such as AIML test case drivers, admin tools etc... Noel said: -- In the purest sense, the interface to an AIML interpreter is just some kind of String getResponse(String). But as all of us know who work on real-world AIML interpreters that are intended for use in multiple contexts, there are so many additional concerns that always need to be handled that it makes sense to have some guidance from a spec about these, too. -- How about model the interfaces after Java Collection. For example, the top most interface you'd have to implement woul be just "String getResponse(String)". Another that inherits from that adds more operations but is more specific to a type of interperter. This would allow you to write tools where if that's all you need -- just the getResponse(String) it would work with most plugin'ed bots. A good example would be if I had written a lot of tools and suddenly wanted them to work w/ pandorabots and the language I wrote it in was C#. I just write XML-RPC specific to pandora bot to the C# interface and boom I'm done. Latter someone else writes one to Java and boom now all your other Java tools you wrote to work with different bots now works w/ XML-RPC and pandora. ----- Original Message ---- From: Noel Bush <noel@...> I think it is great to define a standard interface to an AIML interpreter. Of course, what you're considering expands the scope of "AIML interpreter" somewhat, to include things like loading/reloading AIML sets, setting/getting predicates externally, configuration, and so forth. In the purest sense, the interface to an AIML interpreter is just some kind of String getResponse(String). But as all of us know who work on real-world AIML interpreters that are intended for use in multiple contexts, there are so many additional concerns that always need to be handled that it makes sense to have some guidance from a spec about these, too. It seems somewhat analogous to the aims of the DOM specification, where you want to formally describe a set of common operations that are performed with XML documents. In this case, you want to formally describe a set of common operations that are performed with AIML interpreters. A discussion about this may also draw attention to some potentially interesting questions, such as the degree to which the matching algorithm needs to be part of the AIML spec (i.e., is the trie that is built by many AIML interpreters really the only way to specify/implement the functional requirements of the matching algorithm?). It might also be possible to offer some standardization about handling multiple bots, removing categories, and more. My question is, to what extent would ICE serve as a neutral specification mechanism? Like AIML, it's under the GPL, which is great, but what are its serious competitors? Does it have a chance of being widely adopted, or is it likely to remain associated with this particular company and cause open standards folks to shy away from it? If I understand right from a quick glance at the docs, it looks like the "Slice language" is essentially a C++ library, or something like that. I suppose that would mean that there are a lot of tools around already that can do interesting things with it, like produce other forms of documentation. To what extent does a Slice/ICE specification need to be supplemented with prose? Is it expressively limited or tortured in some way by the basis in C++? The AIML schema, for instance, while able to capture virtually everything about the syntax of AIML, has no way of explaining how AIML is to be processed, so it's necessary to keep a separate specification that defines functionality. It might be sensible to remove all the syntax specification from the AIML spec, and just include the schema, leaving only what cannot be covered by the schema in the spec document itself. But ideally, in the case of AIML as well as in the case of the AIML interpreter interface description, you would like to see everything in one form. An actual implementation is not such a great reference, as it generally includes too many distractions not pertinent to the domain (but here there's more and more along the lines of AOP/injection that can help in uncluttering things). Basically you want as near as you can get to an actual implementation without including anything that is platform- or application- specific. All could be a lot of fun to discuss. Noel _______________________________________________ This is the alicebot-general mailing list Reply to alicebot-general@... Unsubscribe and change preferences at http://list.alicebot.org/mailman/listinfo/alicebot-general Learn netiquette at http://www.dtcc.edu/cs/rfc1855.html Learn to read at http://www.literacy.org/ _______________________________________________ This is the alicebot-general mailing list Reply to alicebot-general@... Unsubscribe and change preferences at http://list.alicebot.org/mailman/listinfo/alicebot-general Learn netiquette at http://www.dtcc.edu/cs/rfc1855.html Learn to read at http://www.literacy.org/ _______________________________________________ This is the alicebot-general mailing list Reply to alicebot-general@... Unsubscribe and change preferences at http://list.alicebot.org/mailman/listinfo/alicebot-general Learn netiquette at http://www.dtcc.edu/cs/rfc1855.html Learn to read at http://www.literacy.org/ _______________________________________________ This is the alicebot-general mailing list Reply to alicebot-general@... Unsubscribe and change preferences at http://list.alicebot.org/mailman/listinfo/alicebot-general Learn netiquette at http://www.dtcc.edu/cs/rfc1855.html Learn to read at http://www.literacy.org/ |
|
|
Re: Internet communications engine.
by drwallace
::
Rate this Message:
Robby Gardner, creator of the Turing Hub, http://www.turinghub.com, is
an active member of the Robitron group, http://groups.yahoo.com/group/robitron. On 10/19/06, mehri <foreverlinux@...> wrote: > Hi Robert. > > I don't think I was around for Robbie's work? Do you happen to have any pointers to it? > _______________________________________________ This is the alicebot-general mailing list Reply to alicebot-general@... Unsubscribe and change preferences at http://list.alicebot.org/mailman/listinfo/alicebot-general Learn netiquette at http://www.dtcc.edu/cs/rfc1855.html Learn to read at http://www.literacy.org/ |
|
|
|
|
|
Port of program-e to phpnuke (beta)
by Pierre mccarragher
::
Rate this Message:
Hello everyone,
I am trying to port Programe-e to a (CMS) phpnuke, as a module. I have put it up on sourceforge and named it NukeAI. I am learning PHP as i go ; so any help would be welcome. See the demo Here @ http://www.divesitenet.com/dive/modules.php?name=NukeAI Sourceforge page @ http://sourceforge.net/projects/nukeai Waterboy _______________________________________________ This is the alicebot-general mailing list Reply to alicebot-general@... Unsubscribe and change preferences at http://list.alicebot.org/mailman/listinfo/alicebot-general Learn netiquette at http://www.dtcc.edu/cs/rfc1855.html Learn to read at http://www.literacy.org/ |
| Free Forum Powered by Nabble | Forum Help |