Devel Digest, Vol 60, Issue 24

Sun Apr 1 22:23:33 EDT 2012


发自我的 iPad

在 2012-3-26，0:00，devel-request at pidgin.im 写道：

> Send Devel mailing list submissions to
>    devel at pidgin.im
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>    http://pidgin.im/cgi-bin/mailman/listinfo/devel
> or, via email, send a message with subject or body 'help' to
>    devel-request at pidgin.im
> 
> You can reach the person managing the list at
>    devel-owner at pidgin.im
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Devel digest..."
> 
> 
> Today's Topics:
> 
>   1. Re: Idea about emoticon cache (John Bailey)
>   2. Re: Disabling some user accounts on our servers (John Bailey)
>   3. Re: GSoC 2012 : Pidgin Plugin Website (John Bailey)
>   4. Re: GSoC 2012 : Pidgin Plugin Website (Eion Robb)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Sun, 25 Mar 2012 09:57:51 -0400
> From: John Bailey <rekkanoryo at rekkanoryo.org>
> To: devel at pidgin.im
> Subject: Re: Idea about emoticon cache
> Message-ID: <4F6F245F.9050007 at rekkanoryo.org>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> On 03/25/2012 05:06 AM, Eion Robb wrote:
>> (someone else feel free to correct me if im wrong, but) Custom emoticons
>> (sending and receiving) work fine in xmpp in pidgin it's just that custom
>> emoticons broke in msn when we changed to msnp16.  I don't think that
>> implementing custom emoticons in any protocol in lib purple is inside the scope,
>> nor necessary for this proposal.
> 
> Eion is correct.  Custom emoticons, buddy icons, and file transfers are all
> broken on MSN currently because we don't support P2Pv2.  I agree with Eion that
> this is outside the scope of an emoticon cache project.
> 
> John
> 
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 836 bytes
> Desc: OpenPGP digital signature
> URL: <http://pidgin.im/pipermail/devel/attachments/20120325/6d07e644/attachment-0001.pgp>
> 
> ------------------------------
> 
> Message: 2
> Date: Sun, 25 Mar 2012 10:14:49 -0400
> From: John Bailey <rekkanoryo at rekkanoryo.org>
> To: devel at pidgin.im
> Subject: Re: Disabling some user accounts on our servers
> Message-ID: <4F6F2859.8000505 at rekkanoryo.org>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> On 03/25/2012 03:11 AM, Mark Doliner wrote:
>> Also note that I don't think I disabled mail for any of these
>> accounts... just shell access.  If you think I shouldn't have disabled
>> any of these, please let me know.
> 
> I thought the mtnsupport user needed a valid shell due to running cron jobs?  We
> can prevent the user from being able to log in over ssh and even at the VM's
> console if we need to.
> 
> John
> 
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 836 bytes
> Desc: OpenPGP digital signature
> URL: <http://pidgin.im/pipermail/devel/attachments/20120325/4728aa8f/attachment-0001.pgp>
> 
> ------------------------------
> 
> Message: 3
> Date: Sun, 25 Mar 2012 10:26:06 -0400
> From: John Bailey <rekkanoryo at rekkanoryo.org>
> To: devel at pidgin.im
> Subject: Re: GSoC 2012 : Pidgin Plugin Website
> Message-ID: <4F6F2AFE.5080001 at rekkanoryo.org>
> Content-Type: text/plain; charset="utf-8"
> 
> On 03/25/2012 03:45 AM, Mark Doliner wrote:
>> This isn't clear.  I'm sure different people have different opinions...
>> 
>> Personally I think it makes sense for plugins to be viewable on a
>> website.  Having them also viewable within Pidgin doesn't seem
>> necessary to me.  After all, why should Pidgin duplicate functionality
>> from a web browser?  However, it kinda depends on how the plugin is
>> installed.
> 
> With our use of Webkit in 3.0.0, not so much would be duplicated, as we could
> tell Webkit to go fetch the page(s) on its own, but I'd rather see this
> particular piece as a plugin.
> 
>> Ease of use of plugins has never been great on Linux.  And packaging
>> to make plugins easier to use is probably a burden for plugin authors.
>> I don't know whether it makes sense to lump these tasks in with this
>> project, but someone may want to consider ways to make this process
>> easier.
> 
> Plugins aren't always the easiest things to use on Windows either.  For example,
> I don't have a functioning Windows installer for the Purple Plugin Pack, so I
> distribute just a zip file containing all the .dll's.  This is apparently a
> difficult concept for some people, even though there's a readme included in the
> archive.
> 
> I've mentioned a setup for plugin distribution before, and I'll repeat it here
> for the sake of reminding people, but it's probably outside the scope of an SoC
> project.  (The scope can always be changed if needed.)  My idea for plugin
> distribution was to steal a page from Adium, OpenOffice, et al, and have our own
> custom file extension that we register on Windows (and if it's easy enough,
> maybe register with GNOME and KDE on non-Windows platforms as well).  I'd
> suggest the route of simplicity here and use a simple zip file with its
> extension changed.  Inside the zip file would be a structure identical to
> .purple's layout, so the plugin's binary would be in a plugins directory inside
> the zip file.  If the plugin uses its own files or a SQLite database or
> something, copies of these files containing default settings could be included
> in the zip file as well.  If we provide install ability though, we'll probably
> need to have an uninstall capability too, which would likely mean we need to
> have some sort of manifest in the zip file so we can know what files to remove
> on uninstall.  Some code in Pidgin to handle the file (which on Linux could be
> some sort of script instead of functionality built into the pidgin binary if we
> want), and it's done.
> 
> The hard part with the above is making sure the right "package" is used in the
> right place.  For example, a binary for Fedora 13 or 14 or whatever is out there
> may not work on Debian or Ubuntu due to library version differences.  Of course
> the same would apply to BSD users, as well.  This *may* be something that can be
> partially ironed out in javascript on the site, though.
> 
>> For example, for Linux users, maybe they could download a .c file, or
>> a zip containing the source, and Pidgin automatically invokes gcc,
>> compiles the plugin, installs it in the user's local ~/.purple/
>> directory, and cleans up after itself.  It would need to show friendly
>> messages if the user needs to install gcc, or needs to install the
>> pidgin-devel rpm or pidgin-dev dpkg.  And it would need to be able to
>> check for updates and update the plugin, possibly automatically.
> 
> I have no strong opinion on this either way, but I would like to point out that
> this has the potential to be a disaster area.  There are security implications
> surrounding downloading and automatically compiling random code, even if it is
> from a website we intend to be trustworthy.  My instinct is to lean toward being
> against the autocompile idea.
> 
> John
> 
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 836 bytes
> Desc: OpenPGP digital signature
> URL: <http://pidgin.im/pipermail/devel/attachments/20120325/c6742f49/attachment-0001.pgp>
> 
> ------------------------------
> 
> Message: 4
> Date: Mon, 26 Mar 2012 04:10:51 +1300
> From: Eion Robb <eion at robbmob.com>
> To: John Bailey <rekkanoryo at rekkanoryo.org>
> Cc: "devel at pidgin.im" <devel at pidgin.im>
> Subject: Re: GSoC 2012 : Pidgin Plugin Website
> Message-ID:
>    <CAFt0mkoxP+miJXk1hLF23p5kT_2eHasA239N9yNzVQ2hHOK93A at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> On Monday, 26 March 2012, John Bailey <rekkanoryo at rekkanoryo.org> wrote:
>> On 03/25/2012 03:45 AM, Mark Doliner wrote:
>>> For example, for Linux users, maybe they could download a .c file, or
>>> a zip containing the source, and Pidgin automatically invokes gcc,
>>> compiles the plugin, installs it in the user's local ~/.purple/
>>> directory, and cleans up after itself.  It would need to show friendly
>>> messages if the user needs to install gcc, or needs to install the
>>> pidgin-devel rpm or pidgin-dev dpkg.  And it would need to be able to
>>> check for updates and update the plugin, possibly automatically.
>> 
>> I have no strong opinion on this either way, but I would like to point
> out that
>> this has the potential to be a disaster area.  There are security
> implications
>> surrounding downloading and automatically compiling random code, even if
> it is
>> from a website we intend to be trustworthy.  My instinct is to lean
> toward being
>> against the autocompile idea.
> 
> I dunno, I kinda like the idea of using something like libtcc to load up .c
> files and run them as plugins, similar to the Perl plugin loader... It
> would make cross-platform distribution of plugins so much easier :)
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://pidgin.im/pipermail/devel/attachments/20120326/89943b11/attachment-0001.html>
> 
> ------------------------------
> 
> _______________________________________________
> Devel mailing list
> Devel at pidgin.im
> http://pidgin.im/cgi-bin/mailman/listinfo/devel
> 
> 
> End of Devel Digest, Vol 60, Issue 24
> *************************************