[alicebot-general] Internet communications engine.

Thu Oct 19 22:50:45 PDT 2006

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 at scattercreek.com>
To: Alicebot and AIML General Discussion <alicebot-general at list.alicebot.org>
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 at list.alicebot.org
[mailto:alicebot-general-bounces at list.alicebot.org]On Behalf Of mehri
Sent: Wednesday, October 18, 2006 11:21 PM
To: alicebot-general at list.alicebot.org
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 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

_______________________________________________
This is the alicebot-general mailing list
Reply to alicebot-general at list.alicebot.org
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 at list.alicebot.org
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/