Community discussions

 
User avatar
boen_robot
Forum Guru
Forum Guru
Topic Author
Posts: 2409
Joined: Thu Aug 31, 2006 4:43 pm
Location: europe://Bulgaria/Plovdiv

[API proposal] "/help" command

Sun Apr 20, 2014 12:08 am

I've written a proposal for a new API specific "/help" command in the wiki:
http://wiki.mikrotik.com/wiki/Proposal_API_help

I'd like to get some feedback from MikroTik, as well as other authors of API clients, API users and editor creators, since this will affect them too.


And before anything else... Yes... I know this is a big addition. Even if immediately approved by MikroTik staff "as is" with an enthusiastic "We'll do it as soon as possible!", I don't expect to see it in the next few RouterOS releases.
PEAR2_Net_RouterOS(1.0.0b6) - My API client in PHP
(Rate my posts? If you want... no pressure...)
 
User avatar
janisk
MikroTik Support
MikroTik Support
Posts: 6283
Joined: Tue Feb 14, 2006 9:46 am
Location: Riga, Latvia

Re: [API proposal] "/help" command

Tue Apr 22, 2014 3:00 pm

regarding hash - you can already check built-time of the package that will correctly reflect on same or other version of packages (even for incorrectly named endless rc1 builds that are about to stop). So, creation of hash can be left for client end as all you have to do is append build-time to hash function number of enabled packages.
[admin@TUD-10g] > sy package print detail 
Flags: X - disabled 
 0   name="routeros-tile" version="6.13rc5" build-time=apr/17/2014 10:16:06 scheduled="" 

 1   name="system" version="6.13rc5" build-time=apr/17/2014 10:16:06 scheduled="" 

 2   name="ipv6" version="6.13rc5" build-time=apr/17/2014 10:16:06 scheduled="" 

 3   name="wireless" version="6.13rc5" build-time=apr/17/2014 10:16:06 scheduled="" 

 4   name="hotspot" version="6.13rc5" build-time=apr/17/2014 10:16:06 scheduled="" 

 5   name="dhcp" version="6.13rc5" build-time=apr/17/2014 10:16:06 scheduled="" 

 6   name="mpls" version="6.13rc5" build-time=apr/17/2014 10:16:06 scheduled="" 

 7   name="routing" version="6.13rc5" build-time=apr/17/2014 10:16:06 scheduled="" 

 8   name="ppp" version="6.13rc5" build-time=apr/17/2014 10:16:06 scheduled="" 

 9   name="security" version="6.13rc5" build-time=apr/17/2014 10:16:06 scheduled="" 

10   name="advanced-tools" version="6.13rc5" build-time=apr/17/2014 10:16:06 scheduled="" 

 
User avatar
boen_robot
Forum Guru
Forum Guru
Topic Author
Posts: 2409
Joined: Thu Aug 31, 2006 4:43 pm
Location: europe://Bulgaria/Plovdiv

Re: [API proposal] "/help" command

Tue Apr 22, 2014 3:38 pm

Indeed, but this requires the client to assume the existence, exact location, format, and semantics of the package print command. In other words, it must assume the existence of the "/system" menu, the existence of the "package" submenu, the existence of the "print" command, and the existence of the "detail" argument, their semantics, as well as assume that the names and times can be found in the "name" and "built-time" properties.

I mean, what if, in v7 for example, you rename "build-time" to "time-built", "build", "compiled-at", "compilation-time", "creation-time" or something similar? Or if the package list is moved from "/system package" to just "/packages" or whatever?

Or (a more likely scenario), if perhaps you allow 3rd party extensions, which you decide will be using a dedicated menu (e.g. "/system extensions", or "/packages mikrotik" + "/packages others"). Those will also have to affect the hash, yet API clients wouldn't immediately know about them.

The whole idea of the "/help" command is to prevent such (and other) assumptions, until reported, replacing them with only assumptions about the "/help" command itself. In the case of the hash, a client only needs to assume that (if there's no !trap reply...), there will be some sort of unique identifier at the "ret" attribute, which identifies the whole set of menus, commands and arguments.

If you're worried about the performance of RouterOS - the hash only needs to be generated once at install/upgrade/downgrade time, or once upon a package (de)activation, after which it can be stored. These things happen fairly rarely, and besides, MD5 or SHA1 are quick to compute. So the impact on the router's performance is therefore non-existent, except at those key (but again - rare) moments, at which point there's a minimal, if not negligible, impact on the CPU. If the hash is stored in RAM for the purpose of quick access, there's only a minimum RAM impact - a few bytes for the hash (16 bytes at minimum for binary MD5, 40 bytes at most for character SHA1).
Last edited by boen_robot on Tue Apr 22, 2014 3:44 pm, edited 1 time in total.
PEAR2_Net_RouterOS(1.0.0b6) - My API client in PHP
(Rate my posts? If you want... no pressure...)
 
User avatar
janisk
MikroTik Support
MikroTik Support
Posts: 6283
Joined: Tue Feb 14, 2006 9:46 am
Location: Riga, Latvia

Re: [API proposal] "/help" command

Tue Apr 22, 2014 3:42 pm

i understand you completely and feature request of this functionality is there since API creation. Unfortunately it is of low priority and as i was told, probably we will see LUA before this.
 
User avatar
boen_robot
Forum Guru
Forum Guru
Topic Author
Posts: 2409
Joined: Thu Aug 31, 2006 4:43 pm
Location: europe://Bulgaria/Plovdiv

Re: [API proposal] "/help" command

Tue Apr 22, 2014 3:50 pm

i understand you completely and feature request of this functionality is there since API creation. Unfortunately it is of low priority and as i was told, probably we will see LUA before this.
Daaaaamn. Knowing how much of a low priority LUA is... that's some REEEEEALLY low priority stuff then.


I understand I'm asking a lot particularly in the area of argument values... But is there any possibility for at least the menu/command list (section 2.2) to be squeezed in? Not as a "high" low priority necessarily... but just "higher than LUA" high.
PEAR2_Net_RouterOS(1.0.0b6) - My API client in PHP
(Rate my posts? If you want... no pressure...)
 
legrang
just joined
Posts: 22
Joined: Wed Nov 03, 2010 4:05 pm
Location: South Africa
Contact:

Re: [API proposal] "/help" command

Tue Jul 14, 2015 12:21 pm

I really wish MikroTik would consider raising the priority on this. Here is my slightly philosophical view on the matter.

We are in a world of software services running everything, with automation and integration becoming the norm. APIs are no longer afterthoughts, but are designed into the core of products and form part of product strategy.

Winbox is great, but it's a tool that's used to setup or troubleshoot, as is the web interface and the command line. Scripting has it's place. The API is different in that it allows us to extend the RouterOS platform do things which we can't using just Winbox or scripting, or to do them easier. Specifically, it allows us to do things which are:
* Centralised
* Autonomous
* More reliable
* Parallel
* More intelligent

Products that allow integration and extension will have a competitive edge on those that do not.

Allowing the user to discover available functionality using the API will allow developers to create applications that can do things that will rival both the existing tools and the competing platforms. Any feature that improves the API should, in my opinion, be near the top of the list, and not the bottom.
Gideon le Grange
RouterOS Java API: https://github.com/GideonLeGrange/mikrotik-java
 
jpillora
just joined
Posts: 4
Joined: Wed Jun 25, 2014 5:18 am

Re: [API proposal] "/help" command

Wed Jul 29, 2015 10:00 am

Any news on this? I think boen_robot's proposal is great! My usecase for this feature is auto-generation of Go (golang) client library. It could be run for each new version and it would generate the appropriate structs and methods for that version.

Who is online

Users browsing this forum: No registered users and 3 guests