On Wed, 24 Feb 2010, susmit shannigrahi wrote:
> 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.
>
My problem is I'm trying to do a cost benefit here, there is a cost for us
to host a webapp, I'm trying to identify something that costs less for you
so we don't say no to you. I'm also trying to understand the benefit.
>From where I sit the free media program is shipping CD's today. When we
agree to host an app like this we're agreeing to do it long after you're
gone.
The map app is a good example, we've have several map outages because it
wasn't properly maintained. Eventually it got back online. It's not
about tg1 vs tg2. It's about wondering who is going to maintain this app
after you're gone.
> >
> >>
> >> >> >> >> 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?
>
Databases existed before webapps, that's why I keep saying scripts.
>
>
> >> > 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.
>
Give us a use case on what the user currently does (start at the very
begining, tell us what URL's to go to and what stuff to hit.
> >> 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.
>
ah, so problem 2: is really just problem 1: restated?
>
> >> 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?
>
the database or the wiki, not both.
> >> 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.
>
Depends on to who.
-Mike
_______________________________________________
infrastructure mailing list
infrastructure@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/infrastructure
