On Wed, Feb 24, 2010 at 8:19 AM, Mike McGrath <mmcgrath@xxxxxxxxxx> wrote: > > On Wed, 24 Feb 2010, susmit shannigrahi wrote: > >> >> What is the difference between writing a script and maintaining that >> >> and writing an simple app and maintaining that? >> >> >> > >> > Tons, in particular the number of libraries it depends on and the security >> > of exposing it to the net. >> >> I understand that. But given that we currently use a lot of TG apps >> and this one uses only python-geoip, python-sqlite, I am not too >> convinced about this argument on risks. It is really possible to make >> it secure when we are using similar other apps. >> > > Unfortunately you don't have to be convinced, we do. There's a time > coming, sooner then we'd like to admit, where our tg1 / python stack won't > be so well supported. This is not a tg1. I would like to understand the problem here. Do you want it in php/mysql? You name it in any language that you want, I shall ensure you have it. > >> >> >> >> >> 3. Currently, in freemedia, we open the form for a day or two and >> >> >> >> close it for the rest of the month. This creates a problem for us. We >> >> >> >> want to keep the form opened for NA for a longer time, EMEA for lesser >> >> >> >> time and so on. In this app, there is a python-sqlite wrapper around >> >> >> >> trac which enables us to differentiate between the regions and >> >> >> >> close/open the form for a region on demand. >> >> >> > >> >> >> > Why not have multiple forms? >> >> >> >> >> >> We have to disable/enable each form using puppet. We have to do it each month. >> >> >> it will not be possible. >> >> >> >> >> > >> >> > Of course it would be. You write a script to generate your pages, change >> >> > a 1 to a 0. >> >> >> >> But I don't have time, not energy to login to puppet every time >> >> someone tells me to do the changes. So will puppet access be given to >> >> current freemedia admins so that they can run the scripts? >> >> >> > >> > So why not have puppet pull from an external resource like the wiki? We >> > do this in Fedora regularly. >> >> >> >> >> >> >> > why not just use a spreadsheet or something? >> >> >> >> >> >> And how do we present the data to the requesters? >> >> > >> >> > how do you do it now? >> >> >> >> Wiki. And requesters have to go through the long list of hundreds of >> >> links. That is not the ideal way, is it? >> >> >> > >> > I'd assume each vendor has a link, will the webapp be getting rid of >> > vendors? If not then they still have to go through a long list, if it's a >> > search thing, why not break out the vendors? >> >> The problem of breaking out the vendors, which is already there, is >> that it is not neat and neither maintainable. >> >> >> >> I saw some thread that we were worried about actually losing our >> >> users. One of the reasons for that low offline availability. It is not >> >> that Fedora is not available offline. It is. But the information is >> >> presented so clumsily that nobody uses that option. >> >> >> > >> > So reorganize the information. >> >> We discussed and worked on it for months and agreed that the current >> method/wiki format is not working properly for us. >> > > So use a database then. And how do we pull the data from the database and present it? PHP is not the ideal one, so how do we show it? >> > Perhaps it would help if you could clearly >> > outline the problems and solutions you're trying to solve. >> >> >> Sure. How many do you want? I shall list five for now but I can bring >> up lot more if required. We have accumulated our problems for one and >> a half years now. >> >> >> Problem 1: Wiki information is not very convenient for the end users. >> We can use tables to make the data more arranged but that breaks the >> page too easily. Again, the admins of freemedia/distribution are >> already overworked and does not want to spend more time on creating >> and maintaining the tables and wiki pages. We want a easy and >> sustainable way of maintaining the list and present them. >> > > What do the end users see now? I thought they used the free media form. No. They need to see the relevant vendor listing when they want to buy and relevant form when they want to request. >> Problem 2: http://lists.fedoraproject.org/pipermail/advisory-board/2010-February/007985.html >> > > That's not a problem, that's a question. Not actually. he, along with other things, points out why such a wiki list is not a very good idea. >> Problem 3: For freemedia, we need keep the form opened differentially >> for different region. Multiple forms are a way, but again, we will be >> moving to more clumsier way of making a list of those forms in the >> wiki. Also, in case something needs to be changed, I have to open all >> those htmls and edit them manually. >> > > so use a database. And how do I fetch it to wiki? >> Problem 4: It is really a pain to organise all the information >> according to countries and continents and maintain them. A better way >> to have a country code and look up those entries dynamically from >> geoip information. >> > > a script can't do that? > >> Problem 5: In the wiki, there is no way to temporarily disable a >> vendor so that it does not come up in the result. We have to delete it >> and again reinsert it. >> > > I think you're missing my point about the vendor information. You can > actually store pages on the wiki via the API. For example: > > wget -qO- > 'https://fedoraproject.org/w/index.php?title=Infrastructure/Server/publictest1&action=raw' > > Pretend that was tab delimited or whatever. If you don't like the wiki > format, don't use wikiformat. But realize it's got to be in some format, > all your problems don't magically go away becuase you're not using wiki > markup. Storing is not that much a problem. Presentation is. How do we present the data with the api? I can even use mwclient and write to a page, but that does not help either. -- Regards, Susmit. ============================================= http://www.fedoraproject.org/wiki/user:susmit ============================================= Sent from Calcutta, WB, India _______________________________________________ infrastructure mailing list infrastructure@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/infrastructure
