Welcome Guest.   Make a donation to an author on the site December 21, 2014, 03:34:33 PM  *

Please login or register.
Or did you miss your validation email?


Login with username and password (forgot your password?)
Why not become a lifetime supporting member of the site with a one-time donation of any amount? Your donation entitles you to a ton of additional benefits, including access to exclusive discounts and downloads, the ability to enter monthly free software drawings, and a single non-expiring license key for all of our programs.


You must sign up here before you can post and access some areas of the site. Registration is totally free and confidential.
 
Free DonationCoder.com Member Kit: Submit Request.
   
   Forum Home   Thread Marks Chat! Downloads Search Login Register  
Pages: Prev 1 [2]   Go Down
  Reply  |  New Topic  |  Print  
Author Topic: FScript2, a new way to build javascript plugins for FARR  (Read 9411 times)
cranioscopical
Friend of the Site
Supporting Member
**
Posts: 4,200



see users location on a map View Profile Read user's biography. Give some DonationCredits to this forum member
« Reply #25 on: January 20, 2011, 11:02:21 AM »

Thanks for sticking with this, ecaradec!

What you're doing has the potential to attain a level of elegance unseen since they closed the Waldorf-Astoria.
Logged

Chris
Armando
Charter Member
***
Posts: 2,683



see users location on a map View Profile Give some DonationCredits to this forum member
« Reply #26 on: January 25, 2011, 04:58:25 PM »

Following this thread. I'm willing to do some testing in my spare time when next version shows up.  Thmbsup

(Why arent the old scattered dlls in the various plugin folders simply crushed by the new fscript version whenever it's updated ? I know that I look stupid at the moment as I'm missing something, obviously...)
Logged

"I suppose it can be said that I'm an absent-minded driver. It's true that I've driven through a number of red lights on occasion, but on the other hand, I've stopped at a lot of green ones but never gotten credit for it."
Glenn Gould
mouser
First Author
Administrator
*****
Posts: 33,792



see users location on a map View Profile WWW Read user's biography. Give some DonationCredits to this forum member
« Reply #27 on: January 25, 2011, 08:27:32 PM »

there is something important that i think needs to be cleared up.

i understand that fscript2 does something very clever in modifying the files inside the other plugin directories.
but this may fail on OS > winxp due to security restrictions, and it seems troublesome.

what i don't understand is if this process is an important part of fscript2, or if it could be avoided by simply having fscript plugin authors release a new version of their plugins with the small new dll included.

Logged
phitsc
Honorary Member
**
Posts: 1,022



see users location on a map View Profile Give some DonationCredits to this forum member
« Reply #28 on: January 26, 2011, 01:39:28 AM »

(Why arent the old scattered dlls in the various plugin folders simply crushed by the new fscript version whenever it's updated ? I know that I look stupid at the moment as I'm missing something, obviously...)

I think it's a fair point. The only problem that comes to mind is compatibility problems for plugins that depend on a certain fscript.dll version. FScript2 would allow them to still use their old version of fscript. But as this is just what we don't want...
Logged

mouser
First Author
Administrator
*****
Posts: 33,792



see users location on a map View Profile WWW Read user's biography. Give some DonationCredits to this forum member
« Reply #29 on: January 26, 2011, 01:46:12 AM »

Quote
Why arent the old scattered dlls in the various plugin folders simply crushed by the new fscript version whenever it's updated ?


my concern is the opposite -- i think trying to delete/modify these files is likely to be problematic to do in an automated fashion.
for me the main goal should be on the other end of the issue -- making fscript2 not need to create or modify files.

i dont think there is anything wrong with forcing existing plugin writers to update their fscript based plugins, and i can even make farr ignore the old directories or do other things, i just think that trying to have one plugin delete/modify files in other plugin directories is very likely to fail in confusing ways on windows vista and win7, which is just not going to let you do this in the program files subdirectory.
Logged
ecaradec
Honorary Member
**
Posts: 408



see users location on a map View Profile WWW Read user's biography. Give some DonationCredits to this forum member
« Reply #30 on: January 26, 2011, 08:22:03 AM »

I agree that the creation of dll on the fly is likely to pose a lot of problems. It felt wrong even when I was doing it. Messing up with the filesystem for something that happens at runtime, not under my control looks like a recipe for disaster.

The reason that those dll are required is that I need something to act as a plugin for FARR and forward all call to Fscript2.

I think it's necessary to create DLL on the fly AND to deploy dll automatically, because of the following reasons :

- There might be bugs even in the proxy, and we would end up with the same issue as fscript1 (much less likely than with fscript 1, but still possible )
- Proxies must be loaded AFTER fscript2.dll otherwise they couldn't forward calls because fscript2 doesn't exists. Locating them in a subfolder of fscript2 is a trick that allow to force FARR to detect them and load them after fscript2.
- If we don't copy the dll automatically, we may end up with binary incompatibility between Fscript2 and its proxy. Copying automatically guaranty that we won't have mismatchs.

If we still go the route of creating dll, I could create them in some other place with less security restriction than "program files". There are places were creating file wouldn't be a issue. It would require to have some FARR support to add another directory as a plugin folder and guaranty that it will load after fscript2.

Another solution would be that fscript2 handle all the script interactions internally, but that would require that I mimic all the FARR behavior inside fscript, and it would not be possible to change aliases, regexes, disable individual plugins, etc... It's too much work.

Another solution would be that FARR support the hosting of multiple plugins inside one DLL, but it's a lot of work for mouser, and tests, etc... as it is the core of FARR plugins.


« Last Edit: January 26, 2011, 10:07:45 AM by ecaradec » Logged

Blog & Projects : Blog | Qatapult | SwiffOut | FScript
mouser
First Author
Administrator
*****
Posts: 33,792



see users location on a map View Profile WWW Read user's biography. Give some DonationCredits to this forum member
« Reply #31 on: January 26, 2011, 08:30:34 AM »

Quote
Another solution would be that FARR support the hosting of multiple plugins inside one DLL

i think it can be done, in one way or another -- ecaradec and i will discuss it more!
Logged
phitsc
Honorary Member
**
Posts: 1,022



see users location on a map View Profile Give some DonationCredits to this forum member
« Reply #32 on: January 26, 2011, 08:44:14 AM »

Quote
Another solution would be that FARR support the hosting of multiple plugins inside one DLL

i think it can be done, in one way or another -- ecaradec and i will discuss it more!

Yes, that sounds like a good solution, if from FARR's point of view it seems feasible.
Logged

Pages: Prev 1 [2]   Go Up
  Reply  |  New Topic  |  Print  
 
Jump to:  
   Forum Home   Thread Marks Chat! Downloads Search Login Register  

DonationCoder.com | About Us
DonationCoder.com Forum | Powered by SMF
[ Page time: 0.04s | Server load: 0.01 ]