>
> Hi Angelo. You've probably hit the nail on the head about organic growth
> right now. I'm looking forward to seeing your collab solution. I guess
> you've decided google offerings are not appropriate.
>
We'll see if I can convert words to action in a meaningful enough way. I
look forward to finishing something useful. Google's products are great. I'm
so satisfied to see a GGroup and a GCode for an OSS project because I know
it's bound to just work. However, when you want to step it up a notch it
only makes sense to branch out to a custom solution. Web service
interoperability just isn't there yet. That's a conversation for another
day.
Greg, as for pledging to authentication and openid projects, the thing to do
> would be to enter all the projects and make a web.py tag so that the
> /tags/web.py page will pull them all up. If you want these projects, go
> ahead and create them. I could make a master project that serves as a focal
> point and links all of them together if desired (though maybe the web.pywiki
> is better for that.
>
Yes, yes, and yes. This seems to be a much better appropriation of funds
than for documentation. An integration of OpenID with this summer's session
project would make the barrier to entry of social apps a cake walk.
BTW: is there an official verdict? When making tags and names for web.py,
> should we make the tag web.py or webpy without a dot like in this group
> name?
>
I've thought about this one myself as well. `Webpy` and `webpy` just don't
look right. In light of Pythonic naming convention, my vote is to maintain
the period.
I'm not sure if Seddit is really the tool to solve the "documenting
> process." When I set out to create it, I had the idea of something
> more like a mailing list. You'll search the archives if you have a
> question, but usually the first place to find your answer will be in
> the documentation. And for documentation, a wiki is certainly the best
> tool for the job. I believe seddit will work well for your "related
> discussion" aspect of the wiki.
>
> I'm interested to see how your hosted solution is coming. I'd be
> interested to talk with you, and see if maybe we can't get seddit
> integrated when it's ready to go live. I think it can solve atleast
> half of the problem.
>
You seddit :). I'm already breaking DRY by rewriting a wiki system. My
intentions were to discuss possible integrations with Seddit (either by me
or by another volunteer) once I had a skeleton up and running. Who better
than the original author? We can resume a private conversation for the
interim if it'll provide more rapid output but we really should keep to the
lists for external input and moderation. Thanks for chiming in though,
seriously.
As for seddit's progress. I don't plan to drop the ball on this one.
> I'll continue to work on it throughout the school year, and get it
> deployed. The summer just wasn't enough time to get specs written up,
> and write a fully function application.
>
I saw all of your pre-dev docs, wireframes, etc. Just curious, was this out
of obligation or necessity?
Also, just curious. Is there anything wrong with prototype and postgresql?
>
I used Prototype prior to jQuery. jQuery simply quadrupled my
AJAX/enlivenment output. As for postgre, I've simply never used it and thus
don't have it installed/configured. Do you have PG specific schema in your
app? We can decide a DB upon integration at a later time.
As for Infogami, I really don't know what to say. I used to use the hosted
version. It was nice. The new dynamic version just isn't very smooth and
shows no signs of eminent change. As for the *new infogami* a.k.a.
OpenLibrary, Tzury would you care to explain? From their tech preview, I see
some neat things going on but a) how is it the new infogami, b) how is it
portable to other applications, and c) what are some of the new features
that would be of interest to our needs?
@ Greg: what is utilitymill's purpose and intent? OSS? I've got a ton of
ideas if you're interested -- especially if you're willing to donate
time/code to this project.
So here's what I'm currently working on and towards:
- OpenID consumption -- anyone who doesn't already have one should get
one.. if you own a domain name and are not using it as a delegate, you
may want to look into it (my OpenID: angelogladding.com; my provider:
myopenid.com)
- Wiki pages -- for documentation and user namespaces -- content types
decide presentation (i.e. Markdown, Python, etc.)
- documentation may contain historic snapshots of code
- user namespaces may contain profile information and sandboxes
for code
- Discussions -- merge IRC & Gmail, like forums, with AJAX (Seddit)
- spawned just like a post to this list
- additionally every wiki page maintains it's own thread (for
annotations and discussion for improvement)
- Track -- further down the road and only if supported by the
community
- integrated code versioning (I'm thinking take SVN down a
decentralized path a la GIT, Bazaar, etc. if sandboxes are utilized)
I just realized something as I refer back to Aaron's `teh communicator` spec
over on the ideas <http://webpy.org/ideas> page. The four items under "web
apps" could be made available in one fell swoop if we can pull this all
together. Furthermore, the pyWeek-esque contests would be trivial to
coordinate in a more cohesive community environment like this (e.g. target
fellow developers based on skills according to profile page in a discussion
forum, start a project wiki page, push code to personal sandboxes, finalize
by merging with main trunk or experimental trunk). Of course why stop there?
It would be just as easy to say that the Tools & Infrastructure upgrades
could be managed as well. I suppose the moral of the story, IMO, is that a
central hub of communication is a vastly important element in expanding a
project with such potential diversity. GGroups just isn't cutting it.
So go grab your OpenIDs, delegate 'em, and start brainstorming a
(re)organizing of docs, discussion, and existing code projects. As promised,
a progress update will come tonight.
Angelo
On 9/8/07, Tzury <[EMAIL PROTECTED]> wrote:
>
>
> I actually meant the *new infogami*, you know, the one that is used in
> the openlibrary.org
> Anyway, once there is an up and running application on the air, I
> think it would be easier for community developers who want to
> contribute for the documentation.
>
>
> On Sep 8, 8:19 pm, Adam Atlas < [EMAIL PROTECTED]> wrote:
> > Well... infogami.com is pretty much abandoned (Aaron sold it to the
> > same company that bought Reddit, I think, and they haven't been
> > developing it any further). Which is a problem because of the
> > relatively meager feature set (and the general lack of support).
> >
> > We used to be using webpy.infogami.com , but we moved the wiki to
> > webpy.org (merging the small amount of content on the old Trac wiki
> > into it) for those reasons. Webpy.org is now powered by "the new
> > infogami", which I'm guessing is the third wikiish web app named
> > "Infogami" written by Aaron. (Infogami.com was the second that I know
> > of, and zpedia.org, another site by Aaron, was "powered by" an
> > "Infogami" that appeared to be a still earlier iteration.) So if
> > we're going by the brand name alone, we *are* using Infogami. And
> > presumably a better one than the one running on infogami.com.
> >
> > On 8 Sep 2007, at 12:39, Tzury wrote:> Guys,
> > > Why not use infogami as the wiki platform for documentation? Am I
> > > missing something?
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"web.py" 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/webpy?hl=en
-~----------~----~----~----~------~----~------~--~---
