Re: Plugin Interface: xchat_list API

[Peter Zelezny <zed@linux.com>]

On 14 Mar 2002 01:33:53 -0800
Alexander Hvostov <root@aoi.dyndns.org> wrote:

> In keeping with my statement above about taking advantage of the
> language's unique characteristics and capabilities, here's what I think
> would be ideal:
> 
> --- BEGIN CODE SNIPPET ---
> XChat xchat; // defined elsewhere
> DCC[] dcc = xchat.getDCCList();
> 
> for (int i = 0; i < dcc.length; i++)
>   System.out.println("File: " + dcc[i].getFile());
> --- END CODE SNIPPET ---
> 
> Notice how much shorter and cleaner my code is.

The problem here is that you have to implement a new method (getDCCList)
everytime a new list is added to plugin.c. Also, if the user tries to use
a new list that wasn't available in earlier versions, their java won't
even compile.


> > If it can be implemented like this, I don't see a need for a function that
> > returns a list of available fields and types. The implementation of
> > xchat.list_str would simply call the C-plugin xchat_list_str and give the
> > result direct (or converted to a Java String). For that, I might remove
> > that "context" field that was causing some confusion.
> 
> And how can I be absolutely sure it's a string and not, say, an integer?

Because xchat_list_str always returns strings, and xchat_list_int
always returns ints. The plugin author knows that "file" is a string,
and "cps" is an int, so they'll call the right function to retreive it.


> If I am to make it so that Java plugins are kept in the proverbial Java
> 'sandbox' that's kept Java applets on the Web so safe, I need to have
> this type safety. Therefore I need some way to get the type of a given
> field.
> 
> I should point out that the only times I've ever managed to get X-Chat
> to crash as a result of running some Java code under my current system
> is under one of three circumstances:
> 
> - There was a bug in my C++ code that connects Java to X-Chat.
> - There was a bug in X-Chat.
> - There was a deficiency in X-Chat's plugin interface that prevented me
>   from implementing a necessary safety mechanism.
> 
> I'd like to eliminate the third one, and not introduce additional
> possibilities. The first two are enough.
> 
> Last but not least, if your insistence on API consistency is a condition
> for the inclusion of my plugin into the main X-Chat tree, then I'd be
> happy to maintain it separately from the main X-Chat tree. I still need
> the functionality needed to enforce safety, though.
> 
> Regards,
> 
> Alex.

I'm not completely hardline on that, I just don't want to repeat the
same mistakes of not making the interfaces extendable.
When I said the interface should all be the same, it doesn't mean you
can't take advantage of some the languages features. But most things should
be the same, for example, I assume you've providing something like
xchat.hook_command/server/print right? It would be best if these functions at
least had the same name as in the C-interface, and roughtly the same args.
No point in calling it xchat.add_command in Java, xchat_hook_command in C
and xchat.add_cmd_handler in python etc.

As for the list API, I think you're example above has potential problems:

1) When new lists are available, Java coders won't see them immediately.
2) When new fields are available, ""
3) Accessing unsupported lists will probably cause javac to bomb out.

Maybe something like this would solve these three:

{
	xchat_list list;

	list = xchat.listGet("dcc");
	if(list)
	{
		for(int i = 0; i < list.length; i++)
		{
			System.out.println("File: " + list[i].getStr("file"));
			System.out.println("Size: " + list[i].getInt("size"));
		}
		list.free();	// or use garbage collection? *shrug*
	}
}

I think the indexing using 'i' is unimplementable though.

-- 
Peter Zelezny. <zed@linux.com>
--
XChat-discuss: mailing list for XChat users
Archive:       http://mail.nl.linux.org/xchat-discuss/