running smoon with python 2.4
by Thomas Schmidt
Hi, I wrote a little patch that allows running
the smoon server in a python 2.4 environment.
Greetings
--
Thomas Schmidt (tschmidt [at] suse.de)
SUSE Linux Products GmbH :: Research & Development :: Tools
"Don't Panic", Douglas Adams (1952 - 11.05.2001)
15 years, 10 months
- 4
- 5
Some changes to Smolt infrastructure
by Yaakov Nemoy
Hey all,
First of all, most of you should be on the mailing list, but I get the
suspicion that some of you are missing. I forwarded some information
about Pavel, our new GSoC student to the list, and it was surprisingly
quiet and bikeshed-painting discussion free. (Maybe that's a good
thing....). Anyways, these changes are important, so I'm spamming all
of you to make sure it gets to the right people.
Toshio and Luke, I included you two in on this for webdev reasons.
You might be interested.
Btw, the mailing list can be found at:
https://fedorahosted.org/mailman/listinfo/smolt-devel
So i've (poorly) implemented a change we should have had 4 months ago.
Namely, I've set up a script that will patch updates into the
database only if the updates havent't already been patched in. This
means a few new rules and concepts for us to work with.
1) We will have a new version numbering scheme. The Smolt program
will continue to use the major.minor.point.subpoint scheme as before.
The database will incorporate a similar major.minor.point numbering
scheme independent of the Smolt program. Every change to the database
will get a version number bump. Period. When you make a change to
the database, be sure to use git to tag your commit with a tag such as
'db1.3.0' or 'db12.40.2'. Ideally, I would like to see every
significant release receive a full major number bump. (Significant is
probably when Mike upgrades the server :P)
2) I lied. Actually, the naming scheme should be
major.minor.point.branch.description, ie db1.3.4.main.hal.version or
db2.34.2.somebranch.experimental.optimization . The regular
expression that parses the version number is:
r'db([0-9]*)\.([0-9]*)\.([0-9]*)\.(\w*)\.(.*)sql$'
3) You will conveniently notice the 'sql$' at the end of that regex.
That's because new changes will go into a file in /databases named
accordingly. Making changes is actually quite simple. Pick a new
revision number in sequence, create a file named after it, insert your
changes, and save. The script /smoon/update-database.py should be
able to figure out the rest. (I say should, because there are still a
few bugs.) On a side note, don't leave the file empty. SQLalchemy
will complain loudly and rudely.
4) To start development anew, first import the initial DDL file. I'm
not sure what we're going to name it, but I think I see a bikeshed
that needs painting. Then run update-database.py. Magic, wow!
5) To get a partially up to date database up to speed, do not import
the initiall DDL file. Just run update-database.py.
6) One more note, don't name the branch anything but 'main'. You will
notice in an article I will post below, that there is a question of
the best way to handle branching and merging. I still need to give
this thought. I included the 'branch' field into the infrastructure
because it is very difficult to fix. Since that table needs to be
present in the database before the script can run, we would need an
older version of update-database.py to upgrade to a newer version.
For the sake of argument, any changes to the table schema_changes ar
probably bad.
The inspiration for this scheme came from this article. Sometimes it
pays to keep up with the closed source development side of things ;).
(Coding Horror is actually a really fascinating blog.)
http://www.codinghorror.com/blog/archives/001050.html
Some notes to specific people.
Ricky, Toshio, Luke, I'm not sure how useful this is to the rest of
the Infrastructure team, but please feel free to pillage. I'm sure
this needs a few more eyes going over it.
Pavel, For your summer work, I want you to feel free to consider any
additions you want to make to the database, for example metadata
tables, or user added information. As per the GSoC stuff, you can
send me SQL code that will upgrade the database, and I will include it
into the main branch. Then, you should rebase your private branch on
top of the new main branch, using git. This way, your weekly patchset
will apply directly on top of our changes.
-Yaakov
PS, should I post this to some other fedora mailing list too?
15 years, 11 months
- 2
- 1
Fwd: Smolt GSoC: Planning Stage 1
by Yaakov Nemoy
I'm going to forward this to the Smolt development list, so they can comment.
---------- Forwarded message ----------
From: Pavel Khardikov <pavel.khardikov(a)gmail.com>
Date: Thu, May 15, 2008 at 4:00 PM
Subject: Re: Smolt GSoC: Planning Stage 1
To: Yaakov Nemoy <loupgaroublond(a)gmail.com>
Hi Yaakov,
If you don't mind, I would like to write about how I see the process
work on the project this summer.
I do not know how it will be correct but it would be easier for me to
work that way.
So It will be very important to know what do you think about this.
1 -- We'll choose AJAX components, JS libraries and widgets that will
be used to presentation data on pages.
2 -- Then I will make sketches of all pages in a vector editor like
the one that I showed you with my GSoC proposal.
You'll look at them and say your opinion about them on the basis of
which we'll continue to work on.
At the design stage of the WebUI I must know exactly what AJAX
components, JS libraries and widgets, I'll use,
so that my sketches will be most similar to how web pages will look then.
To build different types of schedules, I would like to use Flash
Chart. If you are not against it.
IMHO Flash allows to provide datum more convenient and clear to user.
In addition, there is confidence that Flash sites will be properly
displayed in all browsers and on different platforms. I think this is
an important moment.
There are a lot of videos (Flash Video) in the network, it's difficult
to imagine a user without flash plug-in in his browser.
I tried to look on site http://smolts.org with different browsers,
namely: Safari 3.0.4 and opera 9.26 win32 - screens are in the
attachment to the letter.
As I understand all the libraries and components which I'll use must
be open source?
Or am I wrong?
There are 2 version of Flash Chart that I liked:
* http://teethgrinder.co.uk/open-flash-chart/ - open source
* http://www.amcharts.com/ - commercial license
I would like to hear what do you think about this?
3 -- After all the sketches are created I turn to creating templates
of web pages (HTML + JS + CSS + Flash).
The most important thing at this stage will be writing valid HTML +
CSS code which will be equally and properly displayed in different
browsers and on different platforms.
Therefore, It would be very convenient and useful to have deployed
locally Smoon server to have an opportunity,
quickly and easily modify HTML and CSS code and view the results in
different browsers and on different platforms.
4 -- I don't think that would need to change the structure or design
of your database.
My task is to make a pretty Web 2.0 Interface that is to create a new View (UI).
That is, in my opinion amount of datum provided to the user will not
change and will change only the format of their presentation.
5 -- At this stage I would fill html templates with necessary datum,
make and build a tag cloud charts based on data from the database.
At this stage I have learned the TurboGears, Genshi, SQLAlchemy, etc ...
6 -- When most of these tasks will be done I will make my server
public via the Internet so you can look at the results and evaluate
it.
Then we can begin to add new features, documentation for users, etc ...
After I run the server Smoon locally and get any part of the database
from you I'll immediately begin to do this consistently.
As my work, I will give you all my changes compared with the current
version smoon.
--
Best regards. Pavel Khardikov
15 years, 11 months
- 1
- 1
- ← Newer
- 1
- Older →