Winks pluggin, a little work

[Fenix-TX]

Did you patched msnp2p.tcl?... the modifications nedeed there aren't yet in svn.

Zaskar: upload the new plugin to in.solit.us and paste the diff here, like the last time, it was perfect. Thanx for your good job!

Zaskar, vivia said that you upload again the plugin and add the new diff. That diff will be patched on svn when you put the new diff here, with your changes.

PS Good work Zaskar!

[Zaskar]

Fenix-TX: I know, that question was for trip, who said that the plugin didn't worked for him.

[Fenix-TX]

Fenix-TX: I know, that question was for trip, who said that the plugin didn't worked for him.

Ohps! Sorry, well i see that Trap say that, but he replies himself, saying that he had not restart amsn...

[kakaroto]

Hi Zaskar,
Can you please read correctly our posts before answering. Vivia said that you need to modify your plugin and to use events!
no, msnp2p.tcl is not yet patched on SVN, that's because vivia asked you to send the new diff with the PostEvent being called. You do understand that with your current patch, if someone sends us a wink and that your plugin is not loaded, then we'll get a bug like

"::winks::ReceivedWink" command does not exist

.
Anyways, I just committed some changes.. I want you to work with THAT code from SVN version 7719. Here's the diff :

Code:

Index: msnp2p.tcl
===================================================================
--- msnp2p.tcl  (revision 7718)
+++ msnp2p.tcl  (working copy)
@@ -954,6 +954,12 @@
                                                        status_log "VOICE: file <$file> does not exist" red
                                                }
                                               
+                                       } elseif { [lindex [SessionList get $cSid] 7] == "wink" } {
+                                               # Winks support is not in the core, all we can do is support it in the msnp2p code
+                                               # and launch an event for an appropriate plugin to manage it.
+                                               set evPar(chatid) chatid
+                                               set evPar(filename) [file join $HOME winks cache ${filename}.mco]
+                                               ::plugins::PostEvent WinkReceived evPar
                                        } elseif { [lindex [SessionList get $cSid] 7] == "filetransfer" } {
                                                # Display message that file transfer is finished...
                                                status_log "MSNP2P | $cSid -> File transfer finished!\n"
@@ -991,6 +997,8 @@
                                        create_dir [file join $HOME voiceclips]
                                        create_dir [file join $HOME voiceclips cache]
                                        set fd [open "[file join $HOME voiceclips cache ${filename}.wav]" w]
+                               } elseif {$type == "wink" }  {
+                                       set fd [open "[file join $HOME winks cache ${filename}.mco]" w]
                                }
 
                                fconfigure $fd -translation {binary binary}
Index: protocol.tcl
===================================================================
--- protocol.tcl        (revision 7718)
+++ protocol.tcl        (working copy)
@@ -6414,7 +6414,7 @@
 
 }
 
-proc create_msnobj { Creator type filename } {
+proc create_msnobj { Creator type filename {friendly "AAA="} {stamp ""}} {
        global msnobjcontext
 
        if { [file exists $filename] == 0 } { return "" }
@@ -6429,10 +6429,16 @@
 
        set sha1d [::base64::encode [binary format H* [::sha1::sha1 $data]]]
 
-       set sha1c [::base64::encode [binary format H* [::sha1::sha1 "Creator${Creator}Size${size}Type${type}Location${file}.tmpFriendlyAAA=SHA1D${sha1d}"]]]
+       set sha1c [::base64::encode [binary format H* [::sha1::sha1 "Creator${Creator}Size${size}Type${type}Location${file}.tmpFriendly${friendly}SHA1D${sha1d}"]]]
 
-       set msnobj "<msnobj Creator=\"$Creator\" Size=\"$size\" Type=\"$type\" Location=\"[urlencode $file].tmp\" Friendly=\"AAA=\" SHA1D=\"$sha1d\" SHA1C=\"$sha1c\"/>"
+       set msnobj "<msnobj Creator=\"$Creator\" Size=\"$size\" Type=\"$type\" Location=\"[urlencode $file].tmp\" Friendly=\"${friendly}\" SHA1D=\"$sha1d\" SHA1C=\"$sha1c\""
 
+       if { $stamp == "" } {
+               append msnobj "/>"
+       } else {
+               append msnobj " stamp=\"$stamp\"/>"
+       }
+
        set msnobjcontext($msnobj) $filename
 
        return $msnobj

I want you to explicitely use THAT code and make your plugin work with THAT code. your plugin needs to be modified.
First, you must NOT rewrite any of the current procs into your own plugin, what if we ever change the way it works now, huh ? for example in create_msnobj, what if we suddenly change the msnobjcontext into a namespace variable instead of a global variable, then your plugin won't work anymore. So you have to always use our functions, not rewrite them just because you need a little change.
Also note that you rewrote RequestObject in order to specify a filename.. THIS IS WRONG! you must let amsn use the filename it has set internally, you shouldn't override that! once the wink is received you'll get a WinkReceived event being fired with the filename being in there, you should use that and don't rename the file!
The "Location" field of the msnobj is not important at all, it's only the filename of the temp file from the other user's machine, which means we can very easily get many different users with different winks which have the same Location. This is why you should just ignore it, it's only informational, and you shouldn't use that to store the wink into. I also noticed that you request the msnobj without the stamp field (very hacky way to do it btw), why is that ? I would be surprised if you said that it won't work with the stamp in the msnobj.
Also, why did you write the file to $HOME/winks/$cfile/$cfile" ? why twice $cfile ? this is wrong.
I've been looking very briefly at your code, and I know it was hacky, but you can't say that the plugin is finished with code as hacky as it is right now. Please clean it up as much as you can before releasing the plugin.
Amongst other things to clean, I noticed you used "$HOME/winks" in some places for example. NEVER do something like that, what would happen on windows where the separator is the other way around, huh? you must do [file join $HOME winks] instead.
Also, you say you can specify which program to use to extract the cab file. it's false, you can only specify "the path to cabextrat" because you use cabextract specific options to extract the file, if we put the path to 7zip for example, it will just say that it doesn't recognize the options. Also, you use many texts in there without translations. I suggest you translate the text.
Please clean your code, remove the CreateObject and RequestObject from your plugin and use the latest SVN version to make the plugin work against it.
I'll have to review your code later as this seems to be a mess even though it's working.
thx

[Zaskar]

Thanks kakaroto... I've already made the changes for the new event... I was working on it, it was confused because the post said "fireEvent" and it should be "PostEvent"... Anyway, the changes I said before where just for testing, and if you don't have the plugin enabled and someone sends a wink, noone ask for the cab file and so that code is never reached. About being finished and cleaned, I always said that it was not. I said that (for me) it works, but it's not ready at all. I'll do the changes you say now.

About the cabextract, yes, the first idea was to use any extractor but then I had to use some specific arguments and it was not general anymore. I was testing in winxp and I saw that cabextract can only be use to extract a file when we are working in the file's path, if we don't, we get "permission denied", so I've found a WinXp tool "extrac32" and now there's and option to use it instead cabextract. I started to make a readme file and I changed "cab extractor" for "cabextract path", unless you specify to use extrac32 (in that case we don't need the path). In my xp the handmade paths worked, but anyway I'll use [file join] now.

Another trouble was that it was able to send winks between an msn and an amsn, but not between two amsn, it's fixed now.
There are also some imperceptible little improves when receiving a new wink to avoid deal with incomplete data in winks list,. I've added also some ifs to be sure when we extract from an mco.
About the way I separate the fields, it doesn't work when you have an space in one of them, so I've fixed that too.

About the winks_list, now the key is the sha1d and not the wink name, and I'll use that to create the folders, so no problem if to different winks have the same file name.

The last thing.. I've read in some pages that exec command doesn't exist in macs? Is that true? In that case, how can I call the extractor or the player???

I know that the code isn't goot. I'm learning tcl, amsn internals, and part of the messenger protocol while I'm doing it, so please be patience.

[NoWhereMan]

zaskar I suggest you to add a third option beside cabextract and extrac32, "Other", where user can specify a command line like

myextractor -xyzf $fname -p $path
(where $fname will contain the cab name and $path the path to winks cache)
so that you can specify your own.

I'd follow for the vars the same naming conventions (now I don't remember them) used in amsn prefs dialog where you choose the browser and mail client

Same would be for the flash player

btw, even though sure it's hacky (and I haven't tried yet) it's anyway a good job

bye

[Zaskar]

Ok NoWhereMan, it will be the best way.

[kakaroto]

Hello again, NWM idea is good, Zaskar, you can look at how we can do something like that by looking at the code of proc play_sound.
I'll be waiting for an improved version... great work so far, keep it up!

[Zaskar]

About getting the file. I'm now doing this: I don't force any filename, then in ReceivedWink event I get the temp filename from evPar(filename) and I copy that file to the location I want (inside the wink folder and called as the original one).

sha1d has other characters like '/' or '=' so I can't use it directly to name the wink folder. How can I encode it to get a valid name? or what should I use instead?

[NoWhereMan]

md5 ?

[Zaskar]

I don't know exactly how does upvar works, but when you set the filename for the event, you don't give a filename name, you give the value as the final parameter. Now I can't use it from my plugin. It reaches the part when I first used it and abort the proc without showing errors or anything else.

[kakaroto]

Hey Zaskar, I said don't move (nor copy) the file, once you receive it from amsn, use that filename amsn gives you, don't change it! it's already going to be in $HOME/winks/cache/ and it's going to have a unique filename depending on the data and it will have an .mco extension. I told you, don't change it, don't touch the filename, just use it as is!
We know the SHA1D might have non valid characters and that's why amsn already takes cares of giving you a totally unique and valid filename depending on the data. Why would you want to change that ?
about the filename upvar event variable, read the docs and see how to use it, we pass the variable name as parameter so you can upvar it and modify it. Please read the docs or see how other plugins do this, before asking those questions.

[Zaskar]

Ok. I wont move that file, but now I'll have separated parts of the wink in cache and the specific wink folder. I have the idea that cache was something temporal and that I can clear it without major troubles (if I need it I ask for it again like display pics), but if you clear that cache you will loose some winks that are still in menu but can't be sent. In other words: the file in the cache is the cab that cames inside the mco, no the mco, and this is the file that must be sent in the msnobject, but I also need to have the thumbnail and the swf uncompressed to show the menu and play it locally, so that's why I need both thinks.

About upvar, I've made a quick search in google before asking and I didn't found any example other than using a variable name, so I asked. I found an example in another plugin and now it works (but I still don't know why, I'll see later).

[kakaroto]

if you look at how custom emoticons and how displaypictures are, it's the same, the cache/ is the directory for storing the files from the other users, while the directory itself is for your own files. so if you add a wink, it will be in $HOME/winks/ but if you download a wink from another user, then it will be in $HOME/winks/cache Also, the menu to select the wink should show the winks from $HOME/winks not from $HOME/winks/cache. About the wink, it should always be the .mco, not the .swf or whatever. Only keep the mco file, when you need the thumbnail or swf, you could temporarly extract the wink to a directory and keep those files there (or purge the content once you don't need the files, or on the DeInit proc. Also note that this should work when you receive multiple winks at the same time, so the filenames shouldn't be hardcoded, it must be unique depending on the wink, for example :

Code:

set d [filenoext [file basename $filename]]
$cabextract $filename -d $temp/wink-extract-[pid]/$d/

I would also suggest to do it in /tmp instead of $HOME. Other plugins use this method for storing temp files, look at that code (inkdraw for example) to see how to get the temp directory (/tmp for linux, and c:\documents and settings\....\temp for windows, it's all in one environment variable)

About the upvar, I told you to read the how to create plugins in the wiki, it's the first place you should have read...

[NoWhereMan]

About the upvar, I told you to read the how to create plugins in the wiki, it's the first place you should have read...

this is something about the plugin interface which took a bit for me too to figure out, and that they should explain better IMO (if my explanation is correct - I hope so - I would suggest the dev to put it in the dev wiki)

they pass you through the event call the NAME OF A VAR, stored in another var; through upvar you can get the actual VALUE stored in that var they pass you; in fact, this is used to emulate a pass-by-reference call

see:

set test_var 11
set this_is_a_var 100 ;# $this_is_a_var == 100
set varname this_is_a_var ;# $varname == "this_is_a_var"

myevent $varname ;# I know you don't fire events this way, but it's the same

-------------------
how upvar works

upvar SCOPE OUTER_VAR_NAME LOCAL_VAR_NAME

SCOPE is an integer which identifies from which level of the callstack take a variable name, which name is "OUTER_VAR_NAME", and do a reference to its content in a local variable called "LOCAL_VAR_NAME"

then what you'll do in your event proc:

proc myevent { $local_var } {  ;# in our example $local_var is now == "this_is_a_var"

     upvar 2 $local_var mylocalvar ; # $mylocalvar == 100
     status_log "current value of $local_var is $mylocalvar"
 
}


of course you're not limited to the var name you have in $local_var

with upvar 2 test_var local_test ;# you are putting in $local_test a reference to of $test_var of the outer scope which was 11


I hope I was clear (and I hope I was correct, I didn't test, and I'm pretty new with tcl, too.

more on upvar: http://wiki.tcl.tk/1508

Also, the menu to select the wink should show the winks from $HOME/winks not from $HOME/winks/cache.

I don't think this is how the original client works; despite the behavior you have with emoticons, when you receive a new wink you should be able to resend it back... :/