Mark, As usual, thanks for your prompt reply! Installer Maker is a great candidate.
I think that the overall idea can be divided in two categories: 1 - remote driving a plugin workflow. A simple API callable by using dispatch calls could be implemented so that Installer Maker could be "piloted" by a script. This is useful because the user could write driving scripts that integrated installer generation on their own workflow. Not unlike GIT hooks. 2 - receiving events while the plugin is working. There are many steps during installer generation. Installer maker could dispatch an message handler to stacks that registered interest in such progress. Like libURLSetCallback. This way, another script could know of possible errors or when an installer is ready and auto upload it for example. =) On Mon, Feb 13, 2012 at 2:29 PM, Mark Schonewille < m.schonewi...@economy-x-talk.com> wrote: > Hi André, > > I could imagine that Installer Maker would be a candidate for such an API, > but currently I have no clue what people might need. Send in your feature > requests and I'll see what I can do. > > -- > Best regards, > > Mark Schonewille > > Economy-x-Talk Consulting and Software Engineering > Homepage: http://economy-x-talk.com > Twitter: http://twitter.com/xtalkprogrammer > KvK: 50277553 > > Download the Installer Maker Plugin 1.7 for LiveCode here > http://qery.us/za > > On 13 feb 2012, at 17:15, Andre Garzia wrote: > > > Hey Folks, > > > > I've been wondering why most of the plugins for LC do not publish an API > > that developers (and other plugins) can call. Since the addition of > > "dispatch", plugin developers could provide an API in the form of > > dispatchable calls, it would be great. The plugins could dispatch some > > calls to a registered object. This way we could start to exchange data > > between our plugins. For example, I could build a "Dropbox IDE service > > plugin", all plugins wanting to save stuff to dropbox could do it thru my > > service plugin. > > > > In mock xtalk script could go like: > > > > dispatch "register_plugin" to stack "dropbox_service" > > > > put "blablabla" into tParamsA["content"] > > put "file.txt" into tParamsA["filename"] > > dispatch "save_file" to stack "dropbox_service" with tParamsA > > > > This would save other developers the need to implement dropbox on their > own > > for usage inside the IDE. Other useful cases could be for installers, > > Developers who build Installers maker tools, could provide a set of APIs > > that we could call, for example from inside standaloneSaved message. > People > > who build color pickers, could provide an API so that we could call their > > pickers. > > > > I am not saying that we need inter-plugin communications on standalones. > I > > think it is useful to have this kind of technology inside the IDE where > we > > have a dozen plugins that don't talk to each other. > > > > Anyone care for a comment? > > > > Cheer > > andre > > > _______________________________________________ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your > subscription preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode > -- http://www.andregarzia.com -- All We Do Is Code. http://fon.nu -- minimalist url shortening service. _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode