On 16 April 2010 21:32, Antony Vennard <[email protected]> wrote:
>
>
> On 04/16/2010 09:15 PM, Bill Hart wrote:
>> On 16 April 2010 20:54, Antony Vennard <[email protected]> wrote:
>>> Alrighty, sounds good to me, just checking 'cause you've mentioned
>>> "off-list" support a lot...
>>
>> Yes, lots of "off-list" support, which I encourage people to put
>> "on-list" where possible please!
>>
>
> Excellent :D
>
>>>
>>> Yes, Django is my current favourite web framework. I looked at a lot of
>>> PHP frameworks but I couldn't get excited about them and most enforce
>>> MVC and strict url parsing: http://bsdnt.org/class/function/argument ->
>>> class{ function (args} } which isn't massively flexible. Django is happy
>>> either way.
>>>
>>> So I'd need a server with Python installed, preferably 2.6+. mod_wsgi is
>>> also the easiest way of integrating with apache which is what I've been
>>> doing - none of this fancy nginx/lighttpd stuff. Database can be
>>> anything supported - SQLite, MySQL, PostgreSQL. I've heard good stuff
>>> about the latter.
>>>
>>
>> Selmer has mod_wsgi, python 2.6.2, python_django, postgresql
>> installed. I've just sent you a username and password to log in.
>
> Thanks, I'll have a look and start building something up.
>
>>
>>> So that'd basically be the idea - to build a "lite" CMS using Django so
>>> anyone, not just web devs, can add say "news updates" or "version
>>> releases" and modify repository urls, contributor details etc WITHOUT
>>> digging through HTML. It won't be a fully fledged CMS - new content
>>> types will need someone to hack on Django.
>>>
>>> The beauty of this is we can build tools to suit. Trac looks pretty good
>>> and is also python but you could easily re-implement it.
>>
>> Hmm. Trac is pretty sophisticated. I'd be surprised if you could just
>> reimplement it.
>>
>> Also bear in mind I know nothing whatsoever about CMS's. I once used
>> Drupal and found it impossible to figure out. Website stuff is not my
>> thing at all.
>
> Probably not in one hit, but over time. The alternative would be to
> merge it somehow with Django. I've never looked at it from a source
> perspective, but I imagine there's all sorts of interesting combinations
> of trac+django. Their both being python means we can pull trac info into
> Django, too. I expect at least a level of compatibility and interoperation.
>
>>
>>> Name a tool and
>>> we can probably create it quickly enough. Upload a zip file? Submit a
>>> patch? Send a question to the mailing list? Add a sponsor? Add a test
>>> result? Publish a new test matrix? All done relatively easily.
>>>
>>> The rest would be "branding" via CSS and static media such as images,
>>> tarballs and whatever.
>>>
>>> So, I like django. I can however do PHP too if anybody really wants
>>> that. I've never used Ruby but I've heard good things about Rails and
>>> Sinatra.
>>>
>>> Thoughts?
>>
>> Let's keep it pretty simple for now. I personally "get" Ruby. But it
>> has not gained as much of a following as say Python. So I've not put
>> much time into learning it. Moreover, I know very little about rails.
>> I've never personally used PHP, but it is a great language from what I
>> know of it. I've never heard of Sinatra.
>
> Django is a framework on which you build web apps - you basically have a
> copy of its libraries in /usr/lib/python-xx/site-packages on the
> PYTHON_PATH and you create a few files that Django would like to be
> there (or else you tell it something different) and it all magically
> works. The PHP frameworks are conceptually similar in that you have a
> library of PHP classes which are "included" into your current site,
> although it doesn't work quite as cleanly as django, which is on the
> python path.
>
> Python path is comparable to path for executables, LD_LIBRARY_PATH or
> the Java Classpath. It's good.
>
> See djangoproject.com and there's a free "Django book" out there too,
> both of which are really good resources.
>
> CMSes themselves I have never been entirely happy with - there's always
> something not-quite-to-my-liking and customisation is always just out of
> reach. With Django, we don't need a full CMS product (like drupal), we
> can build just the dynamic content we like the idea of and code the rest
> in as html/css. The other thing I forgot to mention is templating - you
> only create one or two base templates and the rest inherit from that,
> minimising the amount of html you have to write which is a massive bonus
> as far as I'm concerned.
>
> I'm no web guru but I know enough to get by - to be honest though, most
> web dev is just a little bit dull. The real fun stuff is written in C...

That's right, which is why I would say keep it simple for now. Better
to have your coding effort spent on writing great C code for us,
rather than reinventing trac. :-)

Looking forward to seeing what emerges on the website front. What we
have for MPIR is currently a pain to maintain and I've never had the
time to learn anything other than html and css (the latter of which I
didn't use for the MPIR website).

Bill.

>
> Antony
>
>>
>> Bill.
>>
>>>
>>> Antony
>>>
>>> On 04/16/2010 08:32 PM, Bill Hart wrote:
>>>> On 16 April 2010 19:53, Antony Vennard <[email protected]> wrote:
>>>>> In addition to the inline:-
>>>>>
>>>>> What's the news r.e. website? When do you want me to start putting
>>>>> something together? Happy to take this discussion off-list if needs be.
>>>>
>>>> Sure, I'm counting on it. And please, let's keep things *on list*.
>>>>
>>>> I can help with content. Do you have an idea what you want to use for
>>>> this? You mentioned django, which I've heard good things about.
>>>>
>>>> Bill.
>>>>
>>>>>
>>>>> Antony
>>>>>
>>>>> On 04/16/2010 07:37 PM, Bill Hart wrote:
>>>>>> On 16 April 2010 19:32, Antony Vennard <[email protected]> wrote:
>>>>>>>
>>>>>>> On 04/16/2010 07:20 PM, Bill Hart wrote:
>>>>>>>>
>>>>>>>> No because one of the conditions is to retain the list of conditions
>>>>>>>> in redistributions, including the third clause.
>>>>>>>
>>>>>>> I thought it was too simple. 2-clause it is then.
>>>>>>
>>>>>> Well I was planning on saying it is preferred and leaving it up to
>>>>>> contributors. The imperative here is to get more regular contribution,
>>>>>> so whatever works really.
>>>>>
>>>>> Sounds good to me. Either or. I was just trying to see if there was a
>>>>> way it would work out easier!
>>>>>
>>>>>>>>>
>>>>>>>>> In my opinion, the only thing missing from the BSD license is 
>>>>>>>>> copyleft -
>>>>>>>>> that said, I can live without it, really - I'd rather use the BSD
>>>>>>>>> license than the LGPL or even worse the GPL.
>>>>>>>>
>>>>>>>> The main thing missing is any form of patent protection. When using
>>>>>>>> these licenses, one must simply request that people make known any
>>>>>>>> patents which affect the project, and all code which might infringe
>>>>>>>> has to be removed. You also ask your contributors to not contribute
>>>>>>>> stuff over which they, or their companies are likely to hold a patent.
>>>>>>>> But in practice, this seems to work for people using these licenses.
>>>>>>>> They just agree to remove code if it becomes a problem.
>>>>>>>>
>>>>>>>> Of course there is nothing stopping someone from having a patent over
>>>>>>>> something that is implemented under the GPL either. But the GPL does
>>>>>>>> stop the contributor from contributing code over which they hold a
>>>>>>>> patent. And if they do, they can't charge a royalty for its use.
>>>>>>>>
>>>>>>>> Come to think of it, now I am confused. How is BSD licensed code
>>>>>>>> compatible with the GPL under these circumstances? If I merged BSD
>>>>>>>> licensed code into my GPL'd project, how do I know the original
>>>>>>>> contributor of the BSD code didn't take out a patent.
>>>>>>>
>>>>>>> I don't suppose you would, but the condition of merging into the GPL
>>>>>>> would be that you had to take the patent out or surrender your right to
>>>>>>> charge for it. I see what you mean though, you ought to be able to GPL
>>>>>>> BSD licensed code and it should just work(tm), which it wouldn't...
>>>>>>
>>>>>> But people do this all the time.
>>>>>
>>>>> Hmmm... I don't know. Is there a legal person we could consult?
>>>>>
>>>>> --
>>>>> You received this message because you are subscribed to the Google Groups 
>>>>> "mpir-devel" group.
>>>>> To post to this group, send email to [email protected].
>>>>> To unsubscribe from this group, send email to 
>>>>> [email protected].
>>>>> For more options, visit this group at 
>>>>> http://groups.google.com/group/mpir-devel?hl=en.
>>>>>
>>>>>
>>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups 
>>> "mpir-devel" group.
>>> To post to this group, send email to [email protected].
>>> To unsubscribe from this group, send email to 
>>> [email protected].
>>> For more options, visit this group at 
>>> http://groups.google.com/group/mpir-devel?hl=en.
>>>
>>>
>>
>
> --
> You received this message because you are subscribed to the Google Groups 
> "mpir-devel" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to 
> [email protected].
> For more options, visit this group at 
> http://groups.google.com/group/mpir-devel?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/mpir-devel?hl=en.

Reply via email to