33 replies to this topic

[Crise]

The recent revival of the discussion about API's got me to look at an old piece of (broken) code I made a while ago and as end result it now seems to work in a satisfactory way.

So now it is time to start asking questions... is plugin api needed in apex if so for what? And what should it be able to do...

[Zlobomir]

Umm, in my lamer nature, I think we (ok, you) need to code smth very small, light and universal, which then could be extended by various additional plug-ins (like Skype and Firefox). So, if you just stated this above in a more scientific way , just let's melt the barrier between theory and practice and let semi-coders work on it, while you move ahead to the next feature.

P. S. I am sure it is operational, from the moment you said "I tried it once and it did not work". I tried my Delphi task maybe over 100 times before it worked.

[Crise]

Firefox like plugins are way out of the scope for this... besides I intentionally do want it to be done in a way that doesn't give plugins too much power, for security reasons.

Also I can't give plugins that much access simply due to the fact that it wouldn't be safe, as DC++ wasn't originally coded with plugins in mind. (and to not hide it, because I am lazy).

[Zlobomir]

But client can always report plug-in status and "power" to hub on connect, and the hub could decide whether to allow access?

[Crise]

Zlobomir, on Jan 25 2008, 09:02 PM, said:

But client can always report plug-in status and "power" to hub on connect, and the hub could decide whether to allow access?

We could yes, but what good would that do as hubsofts do not know how to parse that information we would send...

[Zlobomir]

Crise, on Jan 25 2008, 11:25 PM, said:

We could yes, but what good would that do as hubsofts do not know how to parse that information we would send...

A question of hubsoft development... And we can even "approve" plugins prior to their use I guess. Like with WHQL, but no bypassing. ;-)

[Crise]

Zlobomir, on Jan 26 2008, 01:13 AM, said:

A question of hubsoft development... And we can even "approve" plugins prior to their use I guess. Like with WHQL, but no bypassing. ;-)

Well hubsofts seldom do anything for one single client

Besides before I start to do anything extreme, I want to know if there is any need fir this.

Oh and just for the fun of it, here is something for you guys to look at...

Quote

[03:26:32] *** -= PLUGIN INFO =-
Name: Sample Plugin
Author: Crise
Version: 1.00
Description: Sample plugin project
GUID/UUID: {28ca0266-57aa-4f33-9265-114494beb525}

[03:26:48] *** -= PLUGIN HELP =-
/plugininfo Prints info about the sample plugin
/send <text> Chat message test

[Zlobomir]

Oh stop it! You first propose it yourself, then reject it. I am not so geeky to defend the idea, but this plugin could relace LUA support?

[Crise]

Zlobomir, on Jan 26 2008, 07:34 AM, said:

Oh stop it! You first propose it yourself, then reject it. I am not so geeky to defend the idea, but this plugin could relace LUA support?

One reason that it's being done yes...

[Greg]

So, this going ahead?

[Crise]

Greg, on Feb 16 2008, 12:00 AM, said:

So, this going ahead?

Yes, quite fine in fact... but you can blame spyke for it taking so long as he got this idea of lua plugin in my head

[spyke]

[Crise]

spyke, on Feb 16 2008, 04:46 PM, said:

actually I dropped the lua plugin idea, someone with more knowhow fell free to do it... (my plugin actually worked pretty well, just that rapid calls to eg. nmdch.DataArrival seemed to cause "attempt to call a nil value", a single call worked just fine though)

[spyke]

all good

EDIT: if you can get a api for clientside lua ill take a look into it

Edited by spyke, 16 February 2008 - 06:03 PM.

[Lee]

Moved to our new forum ready for the release of 1.0 final.

[balder]

a lua plugin would be good. but for an API i thin the following functions would be good
*full search feauters (starting with the simple ability to search all loged in hubs)
*start a download
*query download queue
*query upload queue
*query all queue's
*query the statues of the hubs you are connected to (or not)
*basicly exposing as most information as possible in as many ways concivable
*as well as letting search and start a new download
this would allow apps like pidgen, firefox & more to develope some pretty nice plgins

so i gusse i can expect those features in about a week

EDIT: should have probably read this first

[Crise]

Heh, the plugin api in 1.0.1 is very strictly C++ only... and it has other limitations as well, because we pass std::strings to dll, which is only safe when the build environment for the dll is the same as the exe's (I plan on getting rid of the need to pass strings soon though)

[Freebow]

I think plugin feature or lua support can give a huge plus if its done properly. If there is no time or will to do it properly in some future period of time better not do it at all... Apex is still good as it is for MOST of users using it...