[Talk] Plugins Quarantine

chrisglasier

@tig said:

How exactly would you do this ?

Well of course I am no expert but it seems to me that if any of the words used for classes, methods or whatever in the API appear in a plugin then that plugin should simply not work, unless of course the words were used inside a Module. This seems to follow what I see with JavaScript reserved words and duplicated words protected within different directories. If something like this were possible hopefully Sketchup would issue a free patch for their application.

Worth discussing don't you think?

thomthom

Yes, but again - what can we do?

chrisglasier

@thomthom said:

Yes, but again - what can we do?

Give http://forums.sketchucation.com/viewtopic.php?f=323&t=47388 a chance?

thomthom

That's not what I mean - asking the SketchUp developers to change the core of Ruby. Even if that would happen - it wouldn't happen for a very long time.

I mean what can we actually do?

TIG

Your idea only works in plain coded .rb file, because compiled .rbs scripts are inaccessible...
So if some code contains the phrase Sketchup::Group you'd ban it - NO, because that occurs is many ...is_a?(...) test !
Yes... the class Sketchup::Group would be trappable, but what if it made a very unique new addition to the class's method, rather than rewrote an existing one [which should be stopped BUT who compiles the lists etc ?] or then... worse because it now clashed with a matching-named custom method made by another's script [which one gets precedence] ??
I can't see how this wold be manageable by 'us'.
Perhaps an 'obersturmführer' Sketchup-System tool could oversee it, but then I fear a 'terminator' rather that the marginally more preferable 'judge-dread' app...

chrisglasier

@thomthom said:

That's not what I mean - asking the SketchUp developers to change the core of Ruby. Even if that would happen - it wouldn't happen for a very long time.

I mean what can we actually do?

Assuming we can work out and agree a coherent request it may take sometime. But if we could market it on the grounds, say, that existing Trimble users will need new plug-ins for their specialist work; if it could be heavily promoted at the imminent base camp; it may have a chance to be treated as a separate enhancement of the core soon.

Just doing nothing just guarantees it will never happen.

Helping with this in the way I have proposed is really all I am capable of. Sorry.

chrisglasier

@tig said:

Your idea only works in plain coded .rb file, because compiled .rbs scripts are inaccessible...

Doesn't checking get done on selection so the source is irrelevant. In JS the only checking of file content is done if you request validation.

@tig said:

So if some code contains the phrase Sketchup::Group you'd ban it - NO, because that occurs is many ...is_a?(...) test !
Yes... the class Sketchup::Group would be trappable, but what if it made a very unique new addition to the class's method, rather than rewrote an existing one [which should be stopped BUT who compiles the lists etc ?]

I was just thinking of an uncomplicated search of the API for matching words - Alex's cheat sheets come to mind which Jim and I used to make an API machine.

@tig said:

or then... worse because it now clashed with a matching-named custom method made by another's script [which one gets precedence] ??

Well that's the second part of the request -

@unknownuser said:

... and accommodates any possible duplication of names between all plug-ins **.

...

**For example, one suggestion is to reload the .rb file of the selected plug-in so that it overwrites any duplicates.

@tig said:

I can't see how this wold be manageable by 'us'.

It should not be. In developing my own applications I accept that I need to be responsible for ensuring imported devices cannot clash.

@tig said:

Perhaps an 'obersturmführer' Sketchup-System tool could oversee it, but then I fear a 'terminator' rather that the marginally more preferable 'judge-dread' app...

Lost in the imagery!

chrisglasier

... one more on this point

@tig said:

So if some code contains the phrase Sketchup::Group you'd ban it - NO, because that occurs is many ...is_a?(...) test !

Thinks - if all were rejected it would force developers to use Modules. Module names can be duplicated if accommodated on the lines noted in the last post.

chrisglasier

@chrisglasier said:

... one more on this point

@tig said:

So if some code contains the phrase Sketchup::Group you'd ban it - NO, because that occurs is many ...is_a?(...) test !

Thinks - if all were rejected it would force developers to use Modules. Module names can be duplicated if accommodated on the lines noted in the last post.

Or on second thoughts just check all is in Module; if not wrap it in one with plug-in name. Can it be that simple?

Dan Rathbun

Chris, I am sorry. None of your ideas are feasible.

Ruby is much different than JS.
Ruby is a dynamic extensible language, whose modules and classes are MEANT to be modified.
In fact, some of the Extended Ruby libraries modify or extend the base classes, to good effect.
The problem we have is people who do not understand Ruby very well (or do not understand the SketchUp's Ruby environment is shared,) are modifying or extending these classes to the detriment of everyone.
So we cannot freeze base classes permanently, otherwise plugins using some of the extended Ruby libraries will not work.

Also.. Ruby ITSELF has a set of modules, that contain sub-modules and classes that are considered part of the Ruby Core. Just because a class is wrapped within a module, does not make it OK.

TIG is correct, there are many ways in Ruby to change things, without using a class definition block.
ie:

Sketchup;;Group.class_eval {
  def my_funky_method()
    puts("Funky Man!")
  end
}

I CAN think of ways to test some plugins as they are loaded, but that would need to override the global require() and load() methods, which is exactly the kind of thing we are trying to prevent.

Agreed that an author can simply scramble his code or write a compiled C extension, to circumvent any "Ruby Police" utility we may write.

Sorry...

Dan Rathbun

It should also be noted that the new Trimble API Terms of Service prohibit what some of these bad scripts do:
http://www.sketchup.com/resources/api-terms-of-service.pdf

See Section 4 Prohibitions:

@unknownuser said:

4. You will not interfere with or disrupt the APIs or the servers or networks providing the APIs.

chrisglasier

@dan rathbun said:

Chris, I am sorry. None of your ideas are feasible.

Sorry...

No sorry as my Chinese friends say.

I do not have anything like the needed depth of knowledge of Ruby to react further but maybe an ignoramus's proposal may excite more people to question and explore new approaches.

Really my primary interest is exploring reloading imported files to accommodate duplication of names in environments other than html/javascript.

On your last post: As an American you probably understand Prohibition better than me!

chrisglasier

Now that you are awake I want to say that I find what appear to me to be contradictions in what Dan said but I don't have the wherewithal to take them up in a proactive way. For example he wrote:

@unknownuser said:

Ruby is a dynamic extensible language, whose modules and classes are MEANT to be modified.

But then warns of Trimble's prohibition

@unknownuser said:

You will not interfere with or disrupt the APIs or the servers or networks providing the APIs.

and

@unknownuser said:

So we cannot freeze base classes permanently, otherwise plugins using some of the extended Ruby libraries will not work.

If these are not contradictions what I am misunderstanding?

I would really like to see the discussion come to a conclusion/recommendation that can be understood by all ... or at least move in that direction.

TIG

No, Dan is right.
Ruby is a language designed to allow modifications and additions to all classes. and the overwriting of methods etc.
It's just that these changes are often going to break others' tools that anticipate that the API based classes/methods will work as they should.

If selfish/lazy authors publish such code it can be 'blacklisted' when it is discovered, but automatically detecting it as it loads is a whole other ball-game...

We have to trust 3rd-party scripts will do no harm [especially .rbs ones where we can't see the inner workings], but the new RBZ installer does warn users that what they are installing could cause problems...

Unlike Java/JS where actions can happen 'remotely' across the Internet etc and where therefore these languages are 'limited by design' in what they can do to your 'system'/'files', it is relatively simple to write a short Ruby that'd cause complete and utter havoc: for example it could auto-load then auto-run and then find all files in the Plugins and Tools folders etc and then erase them [including itself, to remove the evidence!] - but please don't try this at home !
Actually a few of my scripts already do this kind of thing already discreetly [!]. Say that some main-code files were updated and moved into a subfolder, having the older ones load from Plugins would cause problems - you can tell users to remove them on the reinstall, but some won't d things properly - so my tool auto-loads and auto-runs and if the now-unwanted-files are found in Plugins it deletes them, a dialog tells the user what's happened, and that they need to restart; it's a one-off operation because thereafter the files are not there to be found/erased! But... you see how unscrupulous authors could mess with your Sketchup installation to their own ends - especially with .rbs files !!

thomthom

It's not that JavaScript and Ruby is different in what it allow the developer to do. It's that Websites doesn't share their environment - each window or tab get a separate environment. Each WebDialog is the same.

If JS was picked in SketchUp as the API language you'd have the same problem of namespace issues. A function not wrapped in a namespace would conflict with another.

One could ask why each plugin doesn't get their won environment - but then consider how much overhead that would require to run a separate instance of Ruby for each and everyone of hundreds of plugins. Also - each plugin is accessing the same model entities - how could you place each plugin in a separate environment and still give access to the same model data? You'd get much of the same issues you get with multi-threading.

chrisglasier

How many Ruby plug-in users know about these unbelievable things you have noted especially:

@tig said:

We have to trust 3rd-party scripts will do no harm

it is relatively simple to write a short Ruby that'd cause complete and utter havoc

for example it could auto-load then auto-run and then find all files in the Plugins and Tools folders etc[!*] and then erase them [including itself, to remove the evidence!] - but please don't try this at home !

But... you see how unscrupulous authors could mess with your Sketchup installation to their own ends - especially with .rbs files !!

The only protection is Prohibition no 4?

*emphasised by me

chrisglasier

@thomthom said:

It's not that JavaScript and Ruby is different in what it allow the developer to do. It's that Websites doesn't share their environment - each window or tab get a separate environment. Each WebDialog is the same.

If JS was picked in SketchUp as the API language you'd have the same problem of namespace issues. A function not wrapped in a namespace would conflict with another.

One could ask why each plugin doesn't get their won environment - but then consider how much overhead that would require to run a separate instance of Ruby for each and everyone of hundreds of plugins. Also - each plugin is accessing the same model entities - how could you place each plugin in a separate environment and still give access to the same model data? You'd get much of the same issues you get with multi-threading.

I think there are things here that could be usefully discussed but for the moment I've been totally floored by TIG's exposure.

Dan Rathbun

@chrisglasier said:

Now that you are awake I want to say that I find what appear to me to be contradictions in what Dan said but I don't have the wherewithal to take them up in a proactive way. For example he wrote:

@unknownuser said:

Ruby is a dynamic extensible language, whose modules and classes are MEANT to be modified.

But then warns of Trimble's prohibition

@unknownuser said:

You will not interfere with or disrupt the APIs or the servers or networks providing the APIs.

and

@unknownuser said:

So we cannot freeze base classes permanently, otherwise plugins using some of the extended Ruby libraries will not work.

If these are not contradictions what I am misunderstanding?

In fact, they ARE! Much like most things in life.

A balance is required.

Keep in mind 99% of the SketchUp API is in OEM (Trimble) modules. Trimble could, at any time, elect to freeze all their modules and classes. (I'd hate personally to see it happen, as I like breadboarding API changes so I can file workable API feature requests.) However, even the freezing of module and class objects can be easily circumvented.

The SketchUp API leverages the extensibility of Ruby to extend a few of the base classes ( Numeric and Array, etc.,) but they KNEW what they were doing, and did it in a way that benefits ALL.

There is a big difference when a newbie hacks a base class to only benefit HIS plugin. We KNOW he is a newbie, otherwise he would have created his own subclass of Array, and modified that custom subclass for his own use, and would not have affected any one else's plugins.

So as ThomThom says, ... it's a matter of education first. (And yes there are education issues, now, that we have been wanting to solve on that front. But this is a separate although related issue.)
We only have a problem with a handfull of coders.

Dan Rathbun

What could be done NOW ??

Start a Quarantine List - DONE (good idea Jim!)
Create an "API Health Check Utility" - Some work done by TIG.
Create a code validator / best practice / pitfall finder / absolute no-no checker that coders can run their code through.
Create a run-time environment sentinel tester to see what scrambled or compiled C extensions do. (This cannot be run all the time because it itself must make changes to the Ruby environment. So it's only run during a test session, to test a plugin that's suspected of doing naughty things.) - I think ThomThom is playing with this now?

Dan Rathbun

Also I bring up an old suggestion, by one of our Pythonist members (Jesse James)

He suggested that unwrapped "macro" scripts, be autowrapped on loading within a outer module (I myself played with using the module names Macro or User::Macro,) and an inner module using the basename of the file, as it is done in Python.

So for instance.. a menu item loads a script named "cylinder.rb", but the code in it is unwrapped.
A module would be created for it as: User::Macro::Cylinder, and the code in the file would be evaluated within that module. (I also entertained the idea that a timer would be started, and the module unloaded if the user did not use it again before the timer ran out.)

However this only works for archaic macro-like linear scripts, not modern event driven plugins using observers that need to stay in memory.