On 15 Jan 2009, at 2:31 AM, Maxwell, Adam R wrote:

> On 01/14/09 07:19, "Gregory Jefferis" <jeffe...@gmail.com> wrote:
>
>> On 2009-01-13 23:54, "Maxwell, Adam R" <adam.maxw...@pnl.gov> wrote:
>>
>>>> A second feature allows an optional external script to be called  
>>>> before full
>>>> text doi parsing that can rapidly check a PDF's attributes for a  
>>>> doi or
>>>> check if the pdf name conforms to certain patterns typical of  
>>>> Elsevier or
>>>> Nature Publishing Group journals.  This speeds up addition of  
>>>> some PDFs. I
>>>> guess this would make something hackable by knowledgeable end  
>>>> users.  I have
>>>> such a script that I have been using for a while.
>>>
>>> If there's a way to do this with a script hook, that would be  
>>> preferable;
>>> otherwise, I think a real plugin might be a better approach from a  
>>> security
>>> standpoint...
>>
>> Hmm, perhaps you could spell out the security concerns a bit more  
>> here,
>> because I haven't thought about it too much.  Is there a big  
>> difference
>> between a script hook and providing a hidden preference for a shell  
>> script
>> that is not set in the BD distribution?  Ie it's up to the end user  
>> to
>> download/write their own shell script at their own risk.
>
> My concern is mainly that it's a hidden preference for a shell  
> script that
> runs at times the user may not expect (only when a file is dropped  
> on the
> main window?).  Script hooks are clearly labeled, and the user has a  
> UI to
> see what's enabled and when it will fire.  I have developed a severe
> distaste for hidden preferences, since they generally imply special  
> cases
> and/or untested code paths, and are generally a nuisance.  Worse, if  
> users
> come to rely on them, you can't remove them without someone telling  
> you the
> app is now useless.
>

We could perhaps add support for this through script hooks, I also  
think that would be a better idea. The script hook is basically  
already there: Import Publications. But the DOI stuff is not  
accessible from AppleScript. There are a few parts to this. One is  
getting the DOI from the PDF (or whatever), and the other is getting  
the info from the DOI. The first part would be the responsibility of  
the script hook itself (it can get the file from the linked URLs of  
the imported item). For the second part we could perhaps adapt the  
"import" command. Passing a DOI to this command could use +[BibItem  
itemWithPMID:] to add a new item. The script hook could use this item  
to copy info from, or perhaps the other way around.

Christiaan

> There are also some issues with tasks and pipes; NSTask should  
> generally be
> used in an exception handler, and you need to make sure there are no
> problems with filling the pipe (and then blocking indefinitely).
> BDSKShellTask handles all of this, and also disables SIGPIPE, but  
> running an
> external task does have the potential to hang or crash the calling
> application.  Yeah, it's the user's fault, but minimizing the risk  
> to data
> is important.
>
> -- 
> Adam


------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Bibdesk-develop mailing list
Bibdesk-develop@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bibdesk-develop

Reply via email to