[alicebot-general] Internet communications engine.

[mehri]

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 at aitools.org>

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