Base DroidScript Version Packages?

[Paul Norman]

Hi,

Looking forwards.. perhaps just flying a kite here...

We (a NPO) use a few DroidScript apps as utilities, distributed as "unknown sources" amongst team members.

I was wondering after looking at the sizes of even the smallest ones, if some sort of common "base packages" system was at all viable?

Whereby say an app directly installed, or downloaded from play store, would actually test for, and rely on DroidScript's, here proposed, base packages being present in their correct predefined directories, and if not available on first run, notify the User to install a version numbered base package, providing the option to direct them to the appropriate play store location or to accomplish it themselves manually.

Base packages would be version numbered, in series jumps, meaning that quantum jumps for semantic changes to the DroudScript Api would be possible if deemed absolutly necessary - while older apps would still operate against their own base packages' series number.

The base package(s) would be like Google's WebView which although a base package, can be updated by Google in normal PlayStore User updates as if it were an app itself.

— Which means that flaws, memory or speed enhancements, in earlier series base packages(s), could be safely upgraded without already released apps having to be recompiled and redistributed.

This would mean that individual DroidScript apps would be very light weight, with the base package(s) carrying the main load. Making successive apps very attractive to Users long-term.

This might all be very useful on various kinds of devices with limited resources which will use more than one DS developed app?

As I say, just flying a kite perhaps, no doubt Dave and Chris would have considered this sort of thing before?

Paul

[Dave Smart]

Hi Paul,

Nice idea.. and yes we have considered this but I think it would be far too easy for us to inadvertently break everyone's apps by releasing an update which contain bugs or indeed legitimate bug fixes that lead to side effects.  To do that sort of thing would require a large team of testers too.

I do think there is scope for us to reduce the size of the DS core engine in the future by trimming out some unnecessary resources and moving functionality into plugins.  This is not currently our priority though as our main priority right now is to make DS self funding and sustainable as we currently exist perilously close to the edge of financial insolvency.

There is another way you might want to consider for distributing your utils within your organization though... you could just create a single generic app for your organisation which can launch scripts found in a certain folder.  All your users would then install this app and then you could just distribute your apps as (relatively tiny) SPKs and unzip them into the folder (look in the DS JavaScript source code for spk extraction code).

I have also thought about the Adobe Acrobat operation model before.  We could register a mime type and have a type of file equivalent to a pdf file that just launches the droidscript app 'viewer', but this would probably lead to a security night mare!

Regards

David 

[Paul Norman]

Thanks Dave,

I was sure thought must have been directed to this before.

Appreciate the advice and suggestion for an modular .spk approach within a trusting collaberative group, very helpful thanks, also the overall more pressing priorities that you have for DroidScript at this time.

We're not up for a monthly subscription at this time, being non-commercial we make nothing from Droidscript and probably never will.
Maybe you might give us a PayPal or more likely PlayStore anytime appreciation contribution button on an IDE menu? Say one for $USD10, others for $20, $50 or something?

Yes it occured to me after I posted, that a bug fix could even cause problems, even if developers had become used to relying on the existing bad behaviour - its happened before in other environments - MS I'm looking at you :-)

For some reason I really like your...

>"I have also thought about the Adobe Acrobat operation model before. We could register a mime type and have a type of file equivalent to a pdf file that just launches the droidscript app 'viewer', but this would probably lead to a security night mare!"

It immediately impacts as having something really elegant about it.

Just brainstorming here...

May be some sort of security key system based on a developer being registered with the plugin to make .apks, could be built in, so the Portable Droidscript Format (PDF) :-) will only work if generated by an "apk plugin" registered developer?

And it makes the PDFs come through PlayStore, (or install manually from elsewhere with a security warning as usual) - or as well even via a new DroidScriptCore directly from a central DroidScript registry, which developers pay a small support fee into for using ...

However, the PDF installs as a small very very basic app (with an encrypted internal application script payload), and when run, sends an intent to DroidScript Core app which then loads and runs the PDF's script payload (perhaps on first run loads it into its own disk area for speed on future runs)?

If DroidScriptCore app doesn't like the encrypted security key in the PDF app, no go.

A PDF could then really just be a signed security shell around an SPK, making it safe(r) for public distribution by whatever means?

Paul