Re: [sprog-users] Re: DBI Gear

[Matthew K. <df...@ya...>]

--- Grant McLean <gr...@mc...> wrote:

> On Fri, 2005-07-01 at 21:42 +1000, Matthew Keene
> wrote:
> > --- Grant McLean <gr...@mc...> wrote:

> 
> And likewise, I'd appreciate comments from people
> who are 
> building gears and have questions about how things
> are meant 
> to work (or why) or comments about how things could
> be better.

The obvious thing is more complete documentation.  A
'How To' guide for gear developers would be excellent
- the gear internals guide that you've got is a good
start, but I found it a little lacking in detail (and
I've just read the scheduler internals document and
found some more stuff in there which now starts to
make a bit more sense).  I was planning on making a
start on a step by step guide when I finished writing
the DBI gear, sort of like a 'Gear Development for
Dummies'.  (We're not all rocket scientists, you know
;-)).  Obviously I could only put in the little I know
so far and you have to fill in the rest....

My other main complaint is not related to developing
gears, but a tool usability issue.  When you right
click on a gear on the palette the current behaviour
is that the selected item is executed when you release
the right mouse button.  This isn't my expectation of
how context menus normally work, which is that a right
mouse click simply displays the context menu, and
selecting an item from the menu is a separate mouse
operation (ie when the right button is released the
menu stays displayed until a selection is made or the
menu is dismissed).  This behaviour is particularly
annoying because the default selected menu item is
Delete.  I spent my first five or ten minutes of
playing with the tool cursing at it because the gears
kept disappearing every time I tried to modify their
properties.  Even after I figured it out it still
catches me sometimes.  Can you either change the
context menu behaviour to be more consistent with
other applications, or at the very least can you make
the default selected item something other than Delete
?
> 
> Here are some thoughts from browsing through your
> code ...
> 
> Package Namespace:
> 
> You might not have got the memo, but all
> 'third-party' extensions
> to Sprog should come under the SprogEx namespace. 

You're right, I must have missed that memo.  I must
have stern words with the mail room.
> 
> The 'engage' Method:
> 
> Your gear does all its work in the 'engage' method. 
> The result 
> is that a query which returns a million row result
> set will dump 
> a million messages in the input queue of the next
> gear - which 
> isn't how I intended it too be used.
> 

No problems - I've made the change as you suggested. 
As I suggested, better documentation would have made
this clearer.  I found that it was a little difficult
to work out which methods in the various gears were
related to the framework (ie overriding behaviours frm
the base class) and which were for that gear (or it's
parent classes) only.
> 
> Password Input:
> 
> You can set the password text to be obscured (eg:
> ******), if 
> you want to.  In Glade, select the password Entry
> widget and 
> toggle the 'Text Visible' button from 'Yes' to 'No'.
> 
Yep, although it's still in clear text in the sprog
file.
> 
> POD:
> 
> You obviously haven't gotten around to doing the POD
> yet, but you really
> out to put your own name in the copyright section at
> the very least.
>

Doesn't everybody do the documentation last, after the
fun part's finished ? 

> 

One thing that I'm still a little confused by when
writing the non-blocking version of this gear is how
to give control back to the framework so that other
events can be processed.  The difficulty here is that
I'm going to basically have a single event (executing
the query) which will potentially consume a large
amount of time before any data becomes available.  I'm
planning to call can_read (or some equivalent) on the
IPC file handle to determine whether there the worker
has produced any data to be processed, should I just
return from send_data without sending any messages and
let the scheduler handle the looping, or should I loop
in my send_data method and make some other call in
order to let the scheduler process other events ?  How
often will the scheduler call the input gear's
send_data method if it hasn't yet started producing
any data ?  I'm a little conscious of consuming CPU
needlessly cycling around waiting for data if it's
going to take some time to arrive, and I had been
planning on putting a second or two's sleep time in
the loop just to make sure that it doesn't put a hard
head lock on the CPU.


	

	
		
____________________________________________________ 
Do you Yahoo!? 
Try Yahoo! Photomail Beta: Send up to 300 photos in one email! 
http://au.photomail.mail.yahoo.com