Re: [coldsync-hackers] Anybody up for a perl sync conduit?

[IwantToKeepAnon <iwanttokeepanon at yahoo dot com>]

--- Andrew Arensburger wrote:
> 	conduit 1 handles record 1
> 	conduit 1 handles record 2
> 	conduit 1 handles record 3
> 	...
> 	conduit 2 handles record 1
> 	conduit 2 handles record 2
> 	conduit 2 handles record 3
> 	...
> 	conduit 3 handles record 1
> 	conduit 3 handles record 2
> 	conduit 3 handles record 3
> 	...
> 
> It seems that you're proposing to change this to
> 
> 	conduit 1 handles record 1
> 	conduit 2 handles record 1
> 	conduit 3 handles record 1
> 	...
> 	conduit 1 handles record 2
> 	conduit 2 handles record 2
> 	conduit 3 handles record 2
> 	...
> 	conduit 1 handles record 3
> 	conduit 2 handles record 3
> 	conduit 3 handles record 3
> 	...
> 

Well, it depends on what conduits you are talking
about.  The perl sync conduit would still be called
one db at a time.  So if you mean:

> 	conduit MemoDB handles record 1
> 	conduit MailDB handles record 1
> 	conduit ExpenseDB handles record 1

Then no, I don't mean that.  But if you mean  conduits
for all the same db, then yes you are right on.

As it stands, a db can only be syncd once.  After
that, all the flag information is lost and a second
sync would do nothing.  So your first case scenario
doesn't happen today (for sync, not dump or fetch). 
Am I correct?

So this would be new functionality and it would need
to be designed to work correctly.

As for file/db locking and such, each conduit would
need to have different purposes and as such would not
need the same resources.  I.e. don't create 2
conduits, 1 to save "Personal" memos and 1 for
"Business" memos to the same file, that should be 1
conduit.

You could run a conduit on MemoDB that saved all new
memos to a mysql database and another MemoDB conduit
that saved the "Church notes" category to separate
HTML text files in a websever directory.

So, the 2 conduits serve different functions and use
different resources.

There should be a disclaimer/warning to not create a
conduit that performs complex and long running
operations.  E.g. don't create a MailDB conduit that
sends mail via SMTP or the Web.  If these extra
resources are unavailable, then the PDA could be kept
online for too long or until a timeout occurs causing
a sync failure.

The main advantage in having a flexible sync conduit
in perl is that you can delete records immediately. 
If you delete a record in a dump conduit, it does not
really get deleted until the next sync.

So, back to the mail SMTP/Web example.  There could be
a sync conduit that saves the email and deletes it. 
Then a dump conduit could run against the MailDB
backup (or text file, database, whatever) and sends
the emails.

I have a few dump conduits and fetch conduits.  But if
I delete a record in the dump conduit I have to sync
again right away if I want to clear my PDA of the
deleted records.  I am hoping to stop that.

As for the perl sync design.  I was thinking of just
making a conduit class with methods to overload. 
These methods would be what I earlier called a
"trigger event".  Whenever a save/delete/modify
occurs, the conduit programmer would just overload
that method and do "something".

If it would be better to queue up all the actions,
then you could process all records through each
conduit seperately ... but that would be more work and
I don't know if there would be a payoff.

Let me know your thoughts ...
-- 
rodney

=====
-- 
"A smile is the shortest distance between two people."
Victor Borge

__________________________________
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/
This message was sent through the coldsync-hackers mailing list.  To remove
yourself from this mailing list, send a message to majordomo@thedotin.net
with the words "unsubscribe coldsync-hackers" in the message body.  For more
information on Coldsync, send mail to coldsync-hackers-owner@thedotin.net.