[rkward-devel] Downloadable plugins

[meik michalke]

hi,

am Freitag 01 Oktober 2010 (20:29) schrieb Thomas Friedrichsmeier:
> On Friday 01 October 2010, meik michalke wrote:
> >  - ask newstuff.kde.org for a repository
> 
> Probably needed for easy uploads

and probably reliable creation of XML files, download statistics (if anyone 
needs this) etc. but of course you're right, for testing rounds it's not 
mandatory. somewhere i read that a GHNS repository could be served directly 
from SVN, but the links to further documentation were dead.

> I reckon, we can simply use a repository at
> http://rkward.sourceforge.net/temp/ for testing purposes? You should have
> write access, there, using
>   sftp://m-eik,rkward@web.sourceforge.net/home/groups/r/rk/rkward/

hm, i tried all i could think of (even renewed my password), but i couldn't 
get there. for that matter i fell back to reaktanz.de -- with some minor 
adjustments it works already :-)

> Ok, I've added a button to this effect on the "Plugins"-page of the
> settings dialog, so you have something to start playing with.

haha, first thing i did was a screenshot :-D

> The knsrc-file is in the settings/-subdirectory of the sources, in case you
> want to change it.

good advice, i had to change the provider URL for testing, and the target 
definition, because "TargetDir=rkward-plugins" points to the system wide 
directory, doesn't it? since a normal user cannot drop files there, the 
installation doesn't really work (no error is reported, though). mine looks 
like this right now:

[KNewStuff2]
ProvidersUrl=http://R.reaktanz.de/GHNS/reaktanz-provider.xml
Uncompress=always
InstallPath=.rkward/plugins/

in addition to reaktanz-provider.xml i also created 
 o http://R.reaktanz.de/GHNS/rkward.xml
which holds the actual plugin catalog and is in turn referenced in the 
provider XML file. if you read it, it's not too hard to guess what goes where. 
usually there ought to be three catalogs with a different sorting order 
(latest, most downloads and best rating), but for the time being it all links 
to that one file.

if you would like to test this with the preconfigured sourceforge temp folder, 
someone with write access should copy these two files there:
 o http://R.reaktanz.de/GHNS/rkward-provider.xml
 o http://R.reaktanz.de/GHNS/rkward.xml

you'd either have to rename "rkward-provider.xml" to "provider.xml" or change 
that in the .knsrc file (which should be changed to use "InstallPath=" 
anyway).

long story short: i was able to successfully install the klausuR plugin this 
way. uninstall didn't work, though, but i don't think that's a problem on our 
side (shown as "not installed", but all files were still there, see below).

> As far as I understand the "Uncompress=always" option means that you can
> simply upload a .tar.gz, and it will be unpacked, locally.

yes, "Uncompress=archive" has the same effect, but applies only if an archive 
was downloaded. makes no difference for us, i guess, because we won't host 
wallpapers or stuff like that.

> If you mean keeping the plugins packed, locally, that may be a bit more
> difficult. I suggest unpacking them to separate subdirectories, for now.

well, yes, that was actually my idea ;-) like open office stores it's 
documents in one zipped archive. it has practical advantages:
- uninstall works. GHNS can unpack a downloaded archive, but it doesn't seem 
to keep track of which files go where and hence cannot reverse the process. if 
a plugin remains in one file, GHNS will actually remove it if uninstall is 
chosen.
- installation is safer. if the archive already extists, you must confirm to 
overwrite it. existing unpacked plugin files, on the other hand, will just be 
overwritten without a cough.
- upgrading is more reliable. unpacking a newer version only overwrites the 
existing files, but it wouldn't remove files that are no longer part of the 
new plugin, which could cause problems.

but for the time beeing, we can do without all that, and it wouldn't even 
change a thing for potential plugin contributors if it changed later.

> > Active  Plugin                             Version
> >   [x]   t-test                             0.5.4
> >         Two sample t-test dialog
> >   [ ]   ANOVA                              0.1b
> >         Support for ANOVA
> >   [x]   IRT                                0.5.4
> >         Item response theory (Rasch model)
> >   ...
> 
> I guess that makes a lot of sense in general. But are you sure it should be
> on the level of individual plugins? I think that would be a rather
> overwhelming amount of info, even today. So I'd rather operate on
> .pluginmaps, i.e. collections of plugins, here, as well. What do you
> think?

sure, it's just a sketch. my main concern is that the mere display of a 
.pluginmap path and file name, as is sufficient now, wouldn't be enough. i too 
thought of operating on .pluginmaps still, just changing their appearance 
(adding some useful meta information to get what's what).

it doesn't have to be for each and every menu entry, but on the other hand, a 
toggle for the global all.pluginmap is not really useful either ;-) basically 
my idea is to somehow add to the static all.pluginmap some flexible config 
file that can be altered by a user, e.g. by toggling parts on/off like above.

perhaps something like a blacklist: if none is present, default is that all 
plugins are active. if a plugin gets switched off, it's top level ID from the 
.pluginmap get's added to a $HOME/.rkward/plugin.blacklist kind of file and is 
omitted?

> > i haven't found out about the details of the actually downloaded packages
> > yet, but this is probably handled by the provider service anyway, so we
> > wouldn't have to worry.

it seems the XML files are all that's needed. the actual plugins can be hosted 
anywhere in any format we like, their URL is just referenced in the provider 
files.


viele grüße :: m.eik

-- 
dipl. psych. meik michalke
institut f"ur experimentelle psychologie
abt. f"ur diagnostik und differentielle psychologie
heinrich-heine-universit"at 40225 d"usseldorf
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/rkward-devel/attachments/20101002/0b0081de/attachment.sig>