Subject:
|
Re: Embedded language support in LPub
|
Newsgroups:
|
lugnet.cad.dev
|
Date:
|
Wed, 9 Apr 2003 16:42:58 GMT
|
Viewed:
|
739 times
|
| |
|
|
In lugnet.cad.dev, Don Heyse writes:
> In lugnet.cad.dev, Wayne Gramlich writes:
> > By far the best extensiblity solution is language neutral.
> > With this strategy, you add some code to LPub to allow it
> > to be accessed via a TCP/IP connection. For example, you
> > would add the "-s <port>" option ot LPub to cause it to
> > go into server mode listening on <port>.
> >
> > Everybody else would access LPub via the bi-directional
> > bytes stream interface provided by a TCP/IP stream. For
> > most scripting languages, opening a connection to a port
> > on the local machines is a few lines of code. After that
> > each program would talk to the LPub server via a *simple*
> > protocol that you define.
>
> Yeah, but don't define yet another new protocol. Go with
> a simple protocol that already exists like XML-RPC.
>
> http://www.xmlrpc.org/spec
>
> They don't much simpler than that. Plus if you look at the
> implementations page you'll see that tcl, perl, java, and just
> about everything else are already supported.
>
> http://www.xmlrpc.com/directory/1568/implementations
>
> What could be better than that?
Don:
No matter what stategy is taken, there needs to be a documentation
effort to describe what features of LPub are going to be provided
for extensibility. This is true irrespective of whether a particular
scripting language is selected (e.g. Java/BeanShell, Python, Tcl,
Perl N) or a language neutral RPC stategy is under taken. By the way,
for those of you who aren't into computer science jargon, RPC stands
for Remote Procedure Call.
With regards to XML-RPC, it appears to require a connection set up
and tear down for each command; hence, I doubt it is a very good
match for LPub extensibility.
It is hard to get much simpler than send a command line followed
by a new-line character and get a response back followed by another
new line character. Yes, you have to document the command line
format and response line format, but you have to provide documenation
anyhow. One of the reasons why the LDraw format has been so
successful is because James J. did not go for a complicated format.
The computer science field has spent over two decades coming up
with ever more complicated RPC protocols; I'll list a few here --
rsh (Unix), XDR/RPC (Sun), DCE (OSF), DOE (Sun), CORBA, S-Expressions,
HTTP (W3C), etc. It looks like I'll have to add XML-RPC to the list.
Ultimately, the final decision is up to Kevin.
My $.02,
-Wayne
|
|
Message has 1 Reply:
 | | Re: Embedded language support in LPub
|
| (...) Agreed. It does seem a bit silly to spend all this time discussing languages and protocols when we don't even know what LPUB features will be accessed by said languages and protocols. (...) I'm not sure how you can have those doubts when we (...) (22 years ago, 9-Apr-03, to lugnet.cad.dev)
|
Message is in Reply To:
| | Re: Embedded language support in LPub
|
| (...) Yeah, but don't define yet another new protocol. Go with a simple protocol that already exists like XML-RPC. (URL) don't much simpler than that. Plus if you look at the implementations page you'll see that tcl, perl, java, and just about (...) (22 years ago, 9-Apr-03, to lugnet.cad.dev)
|
31 Messages in This Thread:
 
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
