Re: Suggestion: simple new plugin

Cool! I'll definitely look into that, however what I had in mind is a 
little different.

WHAT I WANTED TO DO:
I started off trying to make a "dumb plugin" that just dumps everything 
that arrives to syncobj_modify_list as individual files in a directory 
somewhere (filenames = UIDs) and similarly gets_changes() by reading the 
contents of another directory. I also intended to comment the code like 
crazy. The purpose of all this was to learn how to build a multisync 
plugin, while at the same time making an easy-to-understand guide for 
other would-be plugin developers like myself.

WHAT I'M ACTUALLY DOING:
Somewhere along the way I realized that this "dumb plugin" could 
actually be of some use to end users if I for example could execute an 
external script with execl() on appropriate occasions and let it do 
modifications and look for changes.

MERITS AND FLAWS:
As I saw it, this approach has two major benefits:

* Completely unrestricted choice of language.

* Very simple interface. The script will get a few well defined 
parameters: what to do (get_changes, modify, ...), modification task 
pickup directory, change report dropoff directory... you get the picture.

This I felt was very good for letting more people contribute to 
multisync. I have a gut feeling that some people may be intimidated by 
the prospect of undertaking a major project in the scary language "C", 
but could very well be capable of implementing the same functionality in 
"INSERT_LANGUAGE_HERE". I know I was.

There may be flaws in my logic here, but the only drawback I can think 
of is speed related. This method means many disk accesses, but on the 
other hand if the other plugin would be for example a bluetooth or even 
IR device, then that will likely be the bottleneck anyway. My purpose is 
functionality first and foremost, and speed comes third. Whether syncing 
takes one or five seconds is irrelevant to me, so I gladly like to leave 
such issues to the competent hands of hardware manufacturers and driver 
programmers.

However - I'd also like to point out that I'm absolutely not against 
implementing things in C should the need arise, but I generally like to 
first wait a bit and see if there is actually a need. So if I can finish 
this plugin and if I or anyone else can develop some sane extension 
script, and my plugin proves too slow to be of any use, and someone 
feels that they're up for implementing it in C instead - please, be my 
guest! That should then be a cakewalk to implement if there's also an 
existing and working implementation in a higher-level language to start 
off from.

QUESTIONS FOR THE DEVELOPERS:
So finally, I have some questions:

* What do the developers think of this idea? Is there anything horribly 
stupid about it that I haven't thought of and should be stopped from 
doing? I'll gladly accept any form of feedback, except in the form of 
computer viruses :-)

* Armin mentioned something about a next major version. What's the 
status on that project? Is there any point in my continuing my plugin 
development if it's going to be implemented in the next major version 
anyway? The comments I've written are off course still there, so it 
might still serve the purpose as a documentational project I guess, but 
would the comments still apply for the next major version?

* Is there any available developer documentation? I mean apart from this 
HOWTO:

http://www.multisync.org/developer/plugin_howto.html

In that case I would be very happy if you guys could point me to it.

* What's the policy on creating directory structures inside the sync 
pair settings directory? Like so, for example:

~/.multisync/1/localdumbplugindir/

with the subdirectories:

change-dropoff-directory/...
modify-task-pickup-directory/...
sync-script-work-directory/...
device-state-after-last-sync-directory/...

It would be very convenient for my plugin project if I could do that. It 
would for example save the end user the trouble of creating/specifying 
those directories some place else (since he/she probably won't want to 
know about these directories anyway).

* What do you want me to call the plugin? I feel that proper naming is 
extremely important in programming. Right now I've named it "sync 
interface" since it's supposed to interface with external sync software. 
Do you have a better suggestion/motivation?

* What is the best way of publishing a plugin to the multisync 
community? I guess you guys will want to take a look at it before I 
start spreading it like the plague... :-)

Thanks for taking the time to read this humongous mail, and thanks also 
for multisync which is a great application!

Best regards,
/Joel Hedlund



Armin Bauer wrote:
> Actually this idea is already being discussed for the next major version
> of multisync. Ill give you a quick introduction how this would be done
> in multisync, since it should be possible to write a plugin like this
> for the current multisync version.
> 
> You would have to write a plugin which loads one script of the needed
> language from the disk. For this to work, you have to include the
> virtual machine for this language somewhere. For python this would be
> done like this: http://docs.python.org/ext/embedding.html
> 
> So you would initialize the parser for the language somewhere, load the
> script "plugin" and then map the plugin functions to the loaded script
> functions.
> 



> On Sun, 2004-09-26 at 16:07, Joel Hedlund wrote:
> 
>>Hi!
>>
>>I'm doing one right now, however I can't guarantee it'll be any good or
>>that it'll be done anytime soon. I guess what I'm trying to do is just
>>what you describe - a siple multisync interface to other external
>>syncing programs that may be written in any language. I'm also trying to
>>solve that exact problem from the link in the first post, namely to
>>enable MultiSync to work with Mozilla Calendar .ics files, possibly on a
>>  webDAV. The reason I want to do it this way is that I feel that there
>>are certain aspects of syncing (like get/put on a webDAV and .ics file
>>parsing) that are simple enough to be adequately filled by small scripts
>>in higher level languages, like for example python. Also, if a simple
>>script interaction multisync plugin existed, this could be put to good
>>use by people with good ideas but are unable to build a C API for
>>multisync (which actually proved quite tricky... :-). Maybe then people
>>would feel more inclined to contribute to multisync and hopefully we
>>would see even more integration and cross-talk among our favorite
>>gadgets and programs.
>>
>>Best wishes to all!
>>/Joel Hedlund
>>
>>
>>Matt Kay wrote:
>>
>>
>>><snip />
>>>
>>>>Just my $POCKET_CHANGE
>>>
>>>
>>>Lol. That seems an equally good way of doing it: it is a bit less 
>>>user-friendly but allows for ssl transfers or transfers to nfs shares 
>>>etc., so is more flexible, and allows for a bit of tidy-up as you suggest.
>>>
>>>What do the developers think about the idea of producing a plugin along 
>>>the lines of the two posts above?
>>>
>>>Best wishes,
>>>Matt
>>>
>>
>>
>>
>>-------------------------------------------------------
>>This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
>>Project Admins to receive an Apple iPod Mini FREE for your judgement on
>>who ports your project to Linux PPC the best. Sponsored by IBM.
>>Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
>>_______________________________________________
>>Multisync-devel mailing list
>>Multisync-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
>>https://lists.sourceforge.net/lists/listinfo/multisync-devel
> 
> 


-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php