Forums Instiki

Requirements for a server-side Instiki scripting package

Subscribe to Requirements for a server-side Instiki scripting package 16 posts, 2 voices

 
tanzer 36 posts

edited almost 6 years ago

I would like to develop a server-side scripting packaging for managing Instiki webs, which will be based on direct calls to the database.

If anyone knows of such a thing already, or even the rudiments of it, do tell – because I’d be glad to use something already existing that meets the bill.

In this thread, I will spell out the requirements that I have in mind. I welcome any comments or suggested modifications to these requirements. Then, in a followup thread, we can talk about how these requirements (for commands) will get translated to SQL update and query statements. Then, in another thread, we can talk about implementation approaches (at the moment I’m leaning towards using Python along with its interface to Mysql).

In any case, on with the requirements…

 
tanzer 36 posts

There are three general use cases that motivate this feature for me.

 
tanzer 36 posts

edited almost 6 years ago

Use Case 1. I want to write scripts to perform the standard administrative operations that are made available from the Edit Web page of Instiki.

 
tanzer 36 posts

edited almost 6 years ago

Sidenote: The saga behind use case 1.

The concrete thing which is motivating me here is that I am running Instiki on hosted server account, and want to manage it securely using https, but my host – RailsPlayground – which has been fantastic in every regard except for this one is having a bunch of technical problems getting https to work well. First, they don’t yet support SNI (server name identification) in Apache, so a dedicated IP, for 2 bucks per month, is required in order to get SSL to work. But worse than that is that they are claiming that the dedicated IP, along with a wildcard SSL certificate for the whole domain, will not work for the whole domain – that actually I’ll need a 2 dollar per month dedicated IP for each application running on each subdomain. On top of this, they say that for each login, they can only provide one dedicated IP!

I was also willing to use lynx and regular http to localhost, but lynx isn’t supported on this shared host. It’s rather confused and annoying. I’ve pleaded my case with them, and the admins are sympathetic, so they are going to escalate the issue internally.

In all fairness, I should say that overall I’m really happy with their service, which provides 5 shell/cPanel accounts, lots of bandwidth and ok storage. Each account gets 200G per month of bandwidth, and 6G of storage. Stuff is backed up (so they say), and custom php.ini is supported. Leaving https aside, these guys are real experts on managing Rails applications, and general system administration, and their level of responsiveness is impressive. The Azimuth wiki has been running without incident (well, just one brief incident, where the web server had to be restarted because Passenger stopped spawning processes), appears more responsive than it was on the previous VPS (at RailsPlaygrond also) that was running the Azimuth wiki, and does not manifest the “Smoke” error to do with growing cookies.

But even apart from this Saga, I rather like writing scripts to do things, so I’d be pretty happy administering Instiki this way.

 
tanzer 36 posts

edited almost 6 years ago

Use Case 2: I want to be able to write scripts to export subsets of the data on one Instiki installation, and import them into other Instiki installations.

 
tanzer 36 posts

The story behind use-case 2.

I maintain one Instiki installation that is competely private, password protected, and not referenced from anywhere on the internet. This is the staging area for Instiki webs that am planning to publish. For some things, I’d rather not think aloud in the open, and would prefer to release when I deem them completed.

I will maintain another Instiki installation for the published webs. It’s also a security precaution, to make sure that my staging webs won’t get compromised if the public installation gets hacked, attacked or spammed.

Now in the staging webs, I will build a full image of what the published webs will contain. To accomplish this, I will just add the line “category:publish:” to any page in a staging web that I want to get published.

So: I’ll want a scripting function that exports all of the data from one installation that is tagged with “publish”, and another one that imports the data into an existing Instiki installation.

 
tanzer 36 posts

Use Case 3: Develop new and more powerful methods for manipulating the data that constitutes Instiki webs.

This is open-ended, and ideas can grow here as we go along.

 
tanzer 36 posts

Functions to support Use-Case 1.

TODO: just read off the functions from the Edit Webs page, and specify them as abstract commands here.

 
tanzer 36 posts

edited almost 6 years ago

Functions to support Use-Case 2.

a) Export. Given an Instiki instance I, define a page set by PageSet(W,C), where W is a list of web identifiers and C is a set of categories. This consists of all pages in webs W that fall under one of the categories in C.

The export function can be given a list of page-set-specifiers (W1,C1), …, (WN,CN). Allow the wildcard specification * for any of the arguments Wi or Ci.

Allow the export to also specify whether the full history should be exported, or just the most recent versions of the pages.

Output of the export statement may be based arounda collection of SQL insert statements, which can be applied to the database for another Instiki installation I’. (To keep the levels clear, let’s defer talk about the SQL specifics to a followup thread.) But as the following functions suggest, some more meta-data may be needed.

 
tanzer 36 posts

b) Delete the page set for (W,C) from the target installation I’.

 
tanzer 36 posts

c) Import a page set P into I’.

Options: (1) overwrite existing pages, and clobber their histories, (2) append to the existing histories, (3) fail if the pages already exist.

There is a constraint here. If the export contains full histories of pages, it doesn’t make sense to use option (2) to append these histories to an already existing history. So if option 2 is specified, then an error should be generated if the imported data contains full histories and the targets already exist.

 
tanzer 36 posts

I believe that these specifications cover the story I mentioned above, which is to publish from one installation to another based on category:publish. They also cover more. For instance, multiple people could each have their own staging installation, and with these scripting commands, they could publish page sets to a common target installation.

 
tanzer 36 posts

edited almost 6 years ago

Please if anyone sees any problems with these requirements, or has suggestions for simplifications, enhancements or new use cases – do tell!

 
tanzer 36 posts

After considering these requirements, and enumerating the commands that are on the Edit Webs page, let’s take a breath, and then move on to discuss the SQL interpretation of these commands in another discussion thread.

Thanks for listening!

 
distler Moderator 110 posts

You might want to look at this page

% ruby bundle exec rake db:fixtures:export_all
...
% ruby bundle exec rake db:fixtures:import_all

which, mind you, is about exporting a whole Instiki instance (rather than just the pages in a category). But it should give you the general idea.

More generally, it seems that what you want to do is write a few Rake tasks for the sort of administrative functions that you want to perform.

That may be worthwhile, even if you eventually get SSL running properly.

Forums Instiki