Re: [Perlplusplugin-developers] authorization?

[Dmitry K. <dk...@pl...>]

	Hi Frank!

On 15 Sep 00 at 16:46, "Frank" (Frank Holtry) wrote:

 >> 
 >> However, the subject of security itself is a tough one, so the real
 >> opsets and wrappers require thorough design.
 Frank> Do you think more needs to be done with opsets than what is
 Frank> currently in np_perl.h?  And you say 'wrappers' as if more than one
 Frank> might be needed?

The sequence of programs and modules involved are currently Prima-oriented,
so to say. But I don't want to make the plugin working only with Prima -
I want to keep it's current functionality, when non-gui scripts could be
launched also. I have now only one wrapper - but it has 'nice GUI' and windows
and all that stuff - but it requires Prima to be installed. Maybe the same
thing will be written latter for Tk.
  The one I have written now, is rather toyish - since when subprogram
fails, it analyzes the output and if it was sort of 'no package blabla
found' it launches either CPAN or PPM gui setups with nice buttons and all
that kind of stuff. But I'm afraid that if opcode-security scheme will be
applied, I'll have to remove them...

 Frank> But if the Prima widgets are designed from the beginning to work
 Frank> with both a plugin and an external event loop, I think it would be
 Frank> a dynamite tool.

I hope also!

 >> But, I read the plugin guide and it says that NPP_SetWindow is called (
 >> in this case) with two different windows, so there's a moment when both
 >> old and new windows are alive? If it is so, then a blocking
 >> notification

 Frank> NPP_SetWindow( NPP instance, NPWindow * window) is what I have for
 Frank> the function, which only has one window pointer.  It's possible the
 Frank> API changed so that both the about-to-be-destroyed window and the
 Frank> newly created window are available.  Is yours different?  

No, I meant that when it's called, the instance have to compare old and new 
windows, ( the code from the samples, for example) to determine the action it 
should take. I thought it should be reasonable, that if netscape says 'go change
from old window to new one' the old window should be accessible in some
way. But even if it's not so, some notification on the window's own handler
should be called before destroy process - in X, I think, it's DestroyNotify
( but it will be useful if only catched within the plugin, not from perl).

 >> And, what way did you signal the perl application?

 Frank> This is really the crux of the problem.  I haven't found a good way
 Frank> to signal the application.  The plugin itself is notified too late
 Frank> to provide a useful signal to the Perl application.  

You mean NPP_SetWindow here? Or DestroyNotify? It would be real bad if
one couldn't reliably catch the Destroy event! But I doubt that such a mighty
mouse as the X11 can't guarantee such a condition.

btw - I'm planning rather not create hacks for Prima in a way it
could communicate with plugin - I'd rather announce a hook for 
the inner event loop, which could be useful for all kind of stuff.
If only that thing would be available in both tk and netscape!

-- 
Sincerely,
	Dmitry