[GSOC] Pidgin Plugin Website

[mrigeshpokhrel]

No I dont think so . That is my roadmap , thats what I wish to accomplish
with the project . I can create a proper functioning website working within
GSOC time frame but then the more extensive features , I'll continue to
work on them after GSOC !!

Hmm URI schemes would be a better option if I don't wanna go with different
file extensions. But then I will loose some aspect of downloading the
plugin on your pc and then installing it. Then again i'll have to extract
it to the plugins directory, which is what I'm trying to avoid .

Suppose I define a uri type pidgin://plugin-name , then this would
definitely start the pidgin plugin browser after revamping it to accept the
uri. But then if I wish to download the "plugin-name" to my pc and then
install it  ? I would have to extract it to the plugins directory. While
what i am trying to do is plugin-name.pidgin , downloading this would start
the pidgin plugin manager/browser and also if i download it to my pc and
try to execute it , that would as well start the pidgin plugin manager. I
hope i'm right on this one .

On Thu, Mar 29, 2012 at 5:24 AM, Eion Robb <eion at robbmob.com> wrote:

> You could also use a custom URI scheme for pidgin plugins, if you didn't
> want to have different file extensions.  On Windows you could register file
> extensions or uri handlers during installation.
>
> Do you think you could get all of that done within the timelines of SoC?
>
> On 29 March 2012 12:02, mrigeshpokhrel <mrigeshpokhrel at gmail.com> wrote:
>
>> Hi all,
>>
>>          I want to work on the pidgin project "Pidgin Plugin Website" .
>> The current pidgin plugin page is pretty bland and requires the user to
>> install the plugins manually. I would like to make the webpage or rather
>> the plugin store more user friendly and also make it easier to install the
>> plugins.
>>
>> I would suggest to do the following:
>>
>> 1. First and foremost making the plugin website more user friendly , like
>> an app store just like android market , or a plugin website to the likes of
>> https://addons.mozilla.org
>>
>>               This would include building the website from scratch ,
>> which I would like to start with HTML5 and JS(Jquery) and later develop it
>> on ROR. Which can be after the GSOC time period.
>>
>> 2. Make the user to click as less links as possible.
>>
>>              This would mean eliminating the need of going to the
>> sourceforge website everytime the user wants to install the link. The main
>> objective of this would be to keep the user in the same page as the plugin
>> eliminating frequent clicks if the user decides to install another plugin.
>>
>> 3. Application MIME handlers (like magnet for torrent clients) for pidgin
>> plugin
>>
>>               As of now the users have to download the plugin and
>> manually install them by extracting the files to the plugin directory
>> (windows)  or by adding a PPA and then installing them using apt-get. In
>> windows using the three major browsers (IE , Firefox , Google Chrome)  this
>> can be performed by adding a registry entry for mime type for internet
>> explorer. Firefox would accept the same MIME type configuration as defined
>> for Internet Explorer earlier, in case it does not , a separate plugin for
>> firefox can include the mime type in the applications tab by editing the
>> firefox profile prefrences (this would work in both windows and linux  and
>> most probably in macos as well). For google chrome we can edit the local
>> user settings to make google handle the mime type , but i have no idea as
>> of now as to how to perform that on windows . Any help on that would be
>> appretiated
>>
>> 4. Revamping the current plugin browser
>>
>>            Presently the plugin browser allows only to enable , disable
>> and configure the plugins . It lacks the feature for installing/removing
>> plugins. I would like to add features like plugin browser , which wold
>> allow the user to browse plugins online and/or download the plugin to the
>> local directory and install the plugin by browsing to the local directory.
>> The plugin browser would also have to be programmed for handling MIME
>> responses and subsequently installing the plugin
>>
>> 5. Developer and user access
>>
>>         The website would have a login/signup portal where a developer
>> can upload the plugin with information like , plugin name , description ,
>> tags , version , pidgin version supported, dependencies and conflicts . And
>> the end user can download , rate , comment on , and provide suggestions for
>> the plugin much similar to the app stores but on a basic standard.
>>
>> Apart from the above features I have few queries regarding them
>>
>> 1. As specified in point 2 , i would like to make the process with as
>> less click as possible for the user . That would mean either totally
>> eliminating the sourceforge link and hosting the plugins in the pidgin
>> server , or else providing the direct link from sourceforge on a new blank
>> page tab. What would be more feasible ?
>>
>> 2. As pidgin already comes bundled with lots of plugins would it be
>> possible to make those plugins installable from the plugin browser itself ,
>> it would be advantageous in the sense that it would decrease the download
>> size of the main application.
>>
>> 3. The MIME handler needs to define a extension such that all requests to
>> that particular extension can be passed on to the pidgin plugin browser
>> capable of handling that MIME response. As of now all the plugins are in
>> .zip format which would create conflicts with major and almost all
>> archiving/compression applications. So there is a need for deciding an
>> extension for the plugins to be specified in the mime type. for eg  .. for
>> a plugin a.zip if we rename it to z.pidgin with "pidgin" as the extension
>> then all the requests made to mime type "pidgin" would be directed to
>> pidgin plugin browser. So, on clicking on a.pidgin download link it would
>> automatically open up the pidgin plugin browser. Any suggestions for the
>> extension type that would be unique and less confusing.
>>
>> Apart from the above any suggestions , queries , requests and critics are
>> welcome.
>>
>> Regards,
>> Mrigesh Pokhrel
>> irc: rAg3-nix , mrigesh
>>
>>
>> _______________________________________________
>> Devel mailing list
>> Devel at pidgin.im
>> http://pidgin.im/cgi-bin/mailman/listinfo/devel
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://pidgin.im/pipermail/devel/attachments/20120329/bc549f7f/attachment-0002.html>