Re: [Webware-devel] RE: WebKit, htmlForDict, WebSkin
Chuck Esterbrook <[EMAIL PROTECTED]> wrote:
> >In the case of HTML/XML, such faithfullness is a significant
> >advantage as this would keep open the option to manipulate
> >templates (HTML/XML + extra template mark-up) with any tool in
> >the ever-growing world of XML tools. (I am quite surprised that
> >*sp frameworks throw away xml-compliancy so easily, making
> >generation of asp or jsp pages, from obvious tool choices such
> >as xslt, require unnecessary twists and acrobatics.)
>
> I don't personally subscribe to the "XML tools" argument, which has been
> presented to me for so long. As of today, I don't personally know anyone
> both using various XML tools and requiring that they work with their
> templates. Actually, I don't know anyone using XML tools. :-)
While I myself wouldn't use many XML tools very often, I would
seriously consider suggesting them for complex, generalized data
entry. Well, *if* I was aware of any tools that work that way. HTML
forms for putting stuff in a database are sorely lacking in many
respects. XML tools for the novice (not the programmer) could be
very useful to describe truly non-HTML structured data.
Though if IE had just kept the HTMLINPUT tag, that would have helped a
lot too. It was such a good idea. Sigh.
> I have an HTML parser (Webware.WebUtils.HTMLTag) that works fine for the
> above. Knowing that HTML is not always precise and that various templating
> languages are already out there, my parser allows arbitrary to
> contain text. Whether or not you want to force the issue after parsing, is
> up to you.
I do it all the time in real HTML, as:
It's quite improper, but it works, and it gets around the fact that
is paragraph-level.
> >Imagine a web application with an extensive user interface, and
> >an abstract description of that interface in, naturally, xml.
>
> Actually, I find these things to be _much_ more natural in CSV than XML.
> Easier to read, edit and process. Admittedly, CSV doesn't do well with
> arbitrarily nested structures. So far, that hasn't been an issue for me.
I must say that MiddleKit's CSV model descriptions are awfully
annoying. I write code in a text editor, the model is part of the
code (even if it declarative), and counting commas is difficult.
But I'd personally prefer it just be a Python expression, like maybe:
Klass('Video', isAbstract=True, attributes=[
Attribute('title', 'string', isRequired=True, min=1, max=100),
Attribute('directors', ['Person'], isRequired=False, max=100),
Attribute('cast', ['Role'], isRequired=False),
])
Or something like that. I don't like 'list of Person', but ['Person']
isn't that good either.
Anyway, XML would still be much more readable for me, and better able
to support future expansion without getting unreadable.
> BTW I CCed webware-devel where these discussions on templating design are
> taking place. Although recently they have quieted down as we have phased
> out of "What should it look like?" to "Who's implementation is doing what?".
I have kind of moved elsewhere, as I've decided I've needed to do
more, um, concretely productive work. But I still kind of like the
ZPT syntax. Specifically, there's no good way to do table-row
repetition solely within a WYSIWYG editor with the Velocity-style
syntaxes (which is, on the larger level, the same syntax that most
template systems use -- i.e., on the text level). It's also nice with
dynamic SRC attributes in a IMG tag, where Velocity-style means you
get a broken image, and also don't get automatic HEIGHT and WIDTH
tags, or whatever else your WYSIWYG editor can do for you.
I also like the ability to use the same system to do HTML-level
transformations. Similar to XSLT, except in a procedural language we
already know (Python).
Ian
___
Webware-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/webware-devel
[Webware-devel] webkit rc script
The webkit rc script includes /etc/rc.d/init.d/functions. My Debian system doesn't have such a file. It seems like the only function used is "success". If that definition was inlined, it would make it more portable. But otherwise it works good. Ian ___ Webware-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/webware-devel
[Webware-devel] Re: [Webware-discuss] WebKit at WWW
Chuck Esterbrook <[EMAIL PROTECTED]> wrote: > At 01:54 PM 5/29/2001 -0500, Ian Bicking wrote: > >If you have an auxiliary directory, how about putting CAdapter in it? > >It really is a lot faster than the Python version, and easier to > >install than mod_python|snake. I've used it happily for quite a while > >now. > > The only question I have at this point is a concern about maintaining the C > Adapter. For example, at first glance it doesn't appear to have retry > feature that the other adapters have. > > mod_webkit is also based on C and I'm wondering if these two guys, > mod_webkit and "C CGI Adapter" should share some C library code. For > example, mod_webkit already has the retry feature. Well, retry is just a code structure issue, not something that could fit in a library. It could be added easily enough. The whole thing is just 248 lines, there's not a lot there to share anyway. The most useful might be the marshalling. mod_webkit uses Python's marshalling functions, I think. I just recreated the small portion needed to send the request, with about 40 lines. The other portion might be reading and parsing address.text, and opening the connection to it. That's 25 lines of C. Not really worthy of reuse. I could add the retry, but just haven't. I would actually prefer to add something that restarted the AppServer upon failure or timeout, as I feel this solves the problem much more robustly than retrying does. I don't think it should be too hard to maintain, really. All the adapters are well partitioned from the rest of Webware. As long as Webware continues to take input over the socket in the same format, the adapter won't need any updating. The one big problem is that it doesn't have any configurability, except to recompile it. Right now there's nothing to configure except the location of address.text, which is just as easily configured with a symbolic link. If there were timeouts and such, those would need configurability, though maybe recompiling would be fine too. Ian ___ Webware-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/webware-devel
Re: [Webware-devel] RE: WebKit, htmlForDict, WebSkin
Chuck Esterbrook <[EMAIL PROTECTED]> wrote:
> At 01:40 PM 5/29/2001 -0500, Ian Bicking wrote:
> >Though if IE had just kept the HTMLINPUT tag, that would have helped a
> >lot too. It was such a good idea. Sigh.
>
> What was that? I never heard of it.
Apparently for a beta (5.0 beta, maybe) they had something like
TEXTAREA... maybe it was called HTMLAREA. Anyway, you could enter
rich text, with bold, italic, etc. IE would then send it as text with
HTML markup. But they took it out :-(
> >I must say that MiddleKit's CSV model descriptions are awfully
> >annoying. I write code in a text editor, the model is part of the
> >code (even if it declarative), and counting commas is difficult.
>
> You're only annoyed because you're using a text editor.
> Use any spreadsheet. Then you will be very happy.
I don't like spreadsheets. I code in Emacs. I read my mail in
Emacs. I love Emacs. I never ever use spreadsheets, why use them for
this one thing?
> You can do this now. Check out the test suite for UserKit. I create an MK
> model there *in Python*.
>
> Knock yourself out. ;-)
I'm unclear, once I've created the model how do I create the store
based on that model?
> I'd also be curious if ArgoUML's flavor of XML could be read *and* if
> ArgoUML is flexible enough to capture non-UML-corresponding aspects of MK's
> model via attribute dictionaries (or some other technique) in the GUI.
> Why? Because then you could define your object model in Argo and use it in
> MiddleKit.
>
> http://www.argouml.org/
I've never really understood what UML languages really offer over just
reading something and thinking about it.
> >I have kind of moved elsewhere, as I've decided I've needed to do
> >more, um, concretely productive work. But I still kind of like the
> >ZPT syntax. Specifically, there's no good way to do table-row
> >repetition solely within a WYSIWYG editor with the Velocity-style
> >syntaxes (which is, on the larger level, the same syntax that most
> >template systems use -- i.e., on the text level). It's also nice with
> >dynamic SRC attributes in a IMG tag, where Velocity-style means you
> >get a broken image, and also don't get automatic HEIGHT and WIDTH
> >tags, or whatever else your WYSIWYG editor can do for you.
>
> I'm not clear on why Velocity breaks images:
>
>
>
> $foo could expand to:
> "foo.gif"
> or even:
> "foo.gif" width=10 height=10
>
> What am I missing?
The WYSIWYG editor would really like to know what image you are
inserting. The editor of course can't find any image named $foo. It
would be easier for it to understand
Or whatever.
> >I also like the ability to use the same system to do HTML-level
> >transformations. Similar to XSLT, except in a procedural language we
> >already know (Python).
>
> Would WebUtils.HTMLTag help at all here? It puts HTML into a Pythonic
> structure. It doesn't have many manipulative conveniences right now. Just
> searching and writing the HTML back out.
Yes. Like I said before, HTMLTag is fairly close to equivalent to the
structure I used. The transformer I used that implemented the
ZPT-style attribute-based language also could be used to transform the
HTML from one form to another. I felt this was best handled as a
transformation, not a method of the HTML parse tree.
To give an example of HTML transformation, here's the code to change
all A HREF tags to use redirects (so you can log it) and have some
JavaScript to hide you are doing that:
def a_transform(node):
if not node.has_key("href"):
# It must be a node, which we don't care about
return node
loc = node["href"]
if loc[:7] != "http://"; and loc[:8] != "https://":
# It's a local site or something, so we don't need to log
return node
node["href"] = '/redirect.cgi?loc=%s' % urllib.quote(loc)
node["onMouseOver"] = "window.status='%s'" % htmlEncode(loc)
node["onMouseOut"] = "window.status=''"
return node
# This is all the cruft that sets up the tranformation.
# This would all be packaged up in a useful function, if given
# a clearer context.
htmlTrans = HTMLTransformer()
tagTrans = TagTransformer()
htmlTrans.addTransformer(tagTrans)
tagTrans.addTransformer("a", a_transform)
htmlSource = HTMLParser(htmlText).parse()
HTMLUnparser(htmlTrans.transform(htmlSource)).unparse()
___
Webware-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/webware-devel
Re: [Webware-devel] RE: WebKit, htmlForDict, WebSkin
Chuck Esterbrook <[EMAIL PROTECTED]> wrote: > >I don't like spreadsheets. I code in Emacs. I read my mail in > >Emacs. I love Emacs. I never ever use spreadsheets, why use them for > >this one thing? > > Because Emacs does not and never will contain the entire world. It doesn't > do diagrams, it doesn't do spreadsheets, it doesn't play video games, it's > not a bash shell (AFAIK), etc. > > And it shouldn't be. If you eventually poured everything in there, you > would have an op sys and a bunch of programs. But we already have that. Yeah, it's called Emacs :) But really, for good reason all code in all languages is easily-editable ASCII, except APL and we all know what happened to them. And maybe visual GUI builders count too, but they have a much more compelling reason to be non-ASCII. Python code is well-structured and far richer than what a spreadsheet can represent, because it structures it in a grammar. No novice is ever going to edit a model description, so it's no hinderance to use. > >I've never really understood what UML languages really offer over just > >reading something and thinking about it. > > If you read and think that doesn't produce anything that someone else can > use. I guess UML becomes more useful as you work with more people. Probably. But I think a good English description is useful too, and general enough to be all-encompassing, flexible enough to be as formal as you desire. And it's easy to inline ASCII representations of the description, and I suppose possible (though more difficult :) to inline spreadsheets. I mean, I'm not *opposed* to them or anything. It just always seemed like organizational cruft to me, but I've never actually been in a situation where they've been used. Ian ___ Webware-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/webware-devel
Re: [Webware-devel] Re: [Webware-discuss] WebKit at WWW
Chuck Esterbrook <[EMAIL PROTECTED]> wrote: > >The whole thing is just 248 lines, there's not a lot there to share > >anyway. The most useful might be the marshalling. mod_webkit uses > >Python's marshalling functions, I think. I just recreated the small > >portion needed to send the request, with about 40 lines. The other > >portion might be reading and parsing address.text, and opening the > >connection to it. That's 25 lines of C. Not really worthy of reuse. > > Disagree. Things like marshalling, reading address.text, reading the config > will continue to grow over time. Why write all this stuff twice? Because it takes so much longer. Really, 40 lines of C -- most of which aren't significant (blank lines, brace marks, trivial wrappers, etc)... is that worth it, really? It would be fine to use marshal.c from mod_webkit otherwise. mod_webkit is configurable through Apache, I can't use that in CAdapter. Well factored is beautiful, but so is small, and they don't always go together. More so with C. I mean, I wouldn't fight a library -- I just don't see the point. mod_webkit is pretty small, CAdapter is pretty small... I really doubt it would be possible to make a good library so that the number of lines total in the library, mod_webkit, and CAdapter are less then they would be without the library. And what have you created? Maybe the worst of all -- an *interface* you have to maintain. > >I could add the retry, but just haven't. I would actually prefer to > >add something that restarted the AppServer upon failure or timeout, as > >I feel this solves the problem much more robustly than retrying does. > > So here's another example. If we write code to restart the app server, I > understand that we have to write it once in Python and once in C. But I > don't ever want to write it four times in Python (which is why we have a > base Adapter class) and twice in C. > > I already have problems with the various AppServer classes which duplicate > code and make maintenance more of a chore. Something like restarting the AppServer requires more than can be done in a library anyway. Personally, I think there should be a command to restart the AppServer and leave it at that -- a .CMD or sh file can handle the actual restarting, since the process may be locally defined anyway. You don't need a library to use system(). > >I don't think it should be too hard to maintain, really. All the > >adapters are well partitioned from the rest of Webware. As long as > >Webware continues to take input over the socket in the same format, > >the adapter won't need any updating. > > It would be strange to have a mismatch in features: > - mod_webkit: will retry, but not restart > - c cgi: will not retry, but will restart > > Our current situation is that switching adapters is a matter of > configuration preference, not functionality. I'd like to keep it that way. It's fine to retry, or whatever... I just don't see how that really helps many real situations. Restarting implies retrying, and if I'm going to put it in I just think I might as well make it more useful than just dealing with the case of a manual restart. This is just my delay tactic, not a plan for complete non-implementation. > >The one big problem is that it doesn't have any configurability, > >except to recompile it. Right now there's nothing to configure except > >the location of address.text, which is just as easily configured with > >a symbolic link. If there were timeouts and such, those would need > >configurability, though maybe recompiling would be fine too. > > CAdapterLib > - read address.text mod_webkit doesn't do this currently. > - read a config file mod_webkit uses Apache's functions. > - retry loop? You can't really abstract this into a library, at least in C, and it would be confusing even if you did. > - restart app I think this should just be a call to system() anyway, though I suppose you could wrap that in a function for later change. But I don't think that's necessary -- you only need one level of abstraction. > - future features X, Y and Z They don't exist yet, so they won't help to fill the library out. Ian ___ Webware-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/webware-devel
Re: [Webware-devel] # in Templates
Tavis Rudd <[EMAIL PROTECTED]> wrote: > There is one point about "What should it look like?" that might > be worthwhile looking at again. In Velocity, WebMacro, and > thus TemplateServer, all directives begin with # and macro > calls are in the form #macroName(). Last night, Mike asked > if this was ideal, in light of comments also starting with #. I think # works well. It's big, even in a proportional font. It's not used much, #1 isn't that common, and the only HTML place is anchors. You aren't like Python anyway, since $ isn't meaningful in Python. DTML has a feature that I never knew of, where you can do &dtml-varname; which is like . The former is nicer than the latter, but it still isn't that nice. Ian ___ Webware-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/webware-devel
Re: [Webware-devel] RE: WebKit, htmlForDict, WebSkin
Chuck Esterbrook <[EMAIL PROTECTED]> wrote: > >Probably. But I think a good English description is useful too, and > >general enough to be all-encompassing, flexible enough to be as formal > >as you desire. And it's easy to inline ASCII representations of the > >description, and I suppose possible (though more difficult :) to > >inline spreadsheets. > > You can't generate anything precise off of an English description, which in > general can't be reasonably formalized (while still being worthwhile to > read, write and parse for these purposes). It goes both ways. All that you can envision representing in code cannot be represented in UML. There is more in heaven and earth than dreamed of in your object model languages. > >I mean, I'm not *opposed* to them or anything. It just always seemed > >like organizational cruft to me, but I've never actually been in a > >situation where they've been used. > > I'll have to hire you some day, so I can make you use models, config files, > metadata, etc. :-) All my models are right up here in my head. You just can't see me tapping meaningfully on my temple right now is all. Ian ___ Webware-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/webware-devel
Re: [Webware-devel] # in Templates
Tavis Rudd <[EMAIL PROTECTED]> wrote: > On Tuesday 29 May 2001 22:07, Ian Bicking wrote: > > I think # works well. It's big, even in a proportional > > font. It's not used much, #1 isn't that common, and the > > only HTML place is anchors. You aren't like Python > > anyway, since $ isn't meaningful in Python. > > I meant the ## comments in TemplateServer rather than > those Python. Anyway, I think I also prefer sticking with # for > everything except for $placeholders. It's consistent and it > definitely is readable. Well, if ## comments seem odd, how about: #comment That's easy, easy to read, and doesn't propogate funny symbols. I think I considerably prefer it to ##, especially since I prefer # as a terminator too, since that feels balanced to me. Ian ___ Webware-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/webware-devel
Re: [Webware-devel] async
On the HTTPServer thread... wouldn't it be easiest to make a HTTPServerAdapter? Or would this imply a speed hit for the socket connection that was the point of using the embedded HTTP server in the first place? Also, eventually there *is* going to be a FTPServerAdapter... if someone else doesn't write it, I'm sure I will. With more than one server involved it's easiest if the AppServer is always expected to be in place. Ian ___ Webware-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/webware-devel
Re: [Webware-devel] # in Templates
Tavis Rudd <[EMAIL PROTECTED]> wrote: > ## comes from Velocity as well. #comment is symmetrical > with the other directives, however. But as # is a comment > in Python you could say that ## is a synonym for #comment ;) #comment is readable, and I know non-programmers really like things they can read aloud, as opposed to lots of punctuation. I suggest it for their benefit. Ian ___ Webware-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/webware-devel
Re: [Webware-devel] # in Templates
Chuck Esterbrook <[EMAIL PROTECTED]> wrote: > Isn't the terminator for TS #; ? > Or was it ;# ? I forget... Yeah. *I* just *think* it should be #. I don't actually remember quite what it is either. Ian ___ Webware-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/webware-devel
Re: [Webware-devel] # in Templates
Tavis Rudd <[EMAIL PROTECTED]> wrote: > On Tuesday 29 May 2001 23:11, Chuck Esterbrook wrote: > > > Well, for what it's worth, I prefer ; > > I think ;# looks awkward at best and confusing at worst. > > I agree with you about that. It's just a pain in the ass to > switch to a single char closure - i.e. create > a parser that would be able to handle all the different types of > directives in addition to $placeholders. Adding a new directive > is currently a 5-10 minute process. I suspect it would be much > more difficult to add new directives to a parser. For the amount > of use the explicit closures are going to see it's just not worth > the effort. To be safe, any use of this syntax in a WYSIWYG editor should use explicit closures -- newlines are meaningless in HTML, and you never can be sure how the editor will treat them, or preserve them. Using the parser shouldn't make your life harder. You don't need a parser for the directives themselves, just the expressions. So you find a #, check that it is followed with a directive, then you grab an expression (if the directive calls for it), maybe another keyword (like "in"), another expressions, etc. You can encapsulate the parser is a single function easily enough, so that it just returns the parsed expression and the point where the expression ended. Ian ___ Webware-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/webware-devel
Re: [Webware-devel] # in Templates
Just bite the bullet already and use the parser! It won't be 1.0 until you use a parser, no matter what, because this is only one syndrome of the lack of a parser among many syndromes. Tavis Rudd <[EMAIL PROTECTED]> wrote: > On Tuesday 29 May 2001 23:34, Ian Bicking wrote: > > To be safe, any use of this syntax in a WYSIWYG editor > > should use explicit closures -- newlines are meaningless > > in HTML, and you never can be sure how the editor will > > treat them, or preserve them. > > Good point. You raised this before, but I'd forgotten. > > Short of going the parser route how about > #if $test /# > instead of > #if $test ;# > ? > > ___ Webware-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/webware-devel
Re: [Webware-devel] # in Templates
Tavis Rudd <[EMAIL PROTECTED]> wrote: > I have no qualms about using the parser > for that stuff (... I wish I had the time). However, I still think > it's not worth the effort for the directives and I actually > prefer /# to ; for a closure. It's more visible. I might reconsider > at a future date when I have more time. No, it's not worth it for the directives. But it means a change to grabbing just the start of the directive, and walking through until the end. I.e., you don't search for the end of the entire directive, you parse what you need to parse and make sure that it is terminated correctly. This gives better error messages too. > Ian, I find it ironic that you who 'uses Emacs for everything' > is so aware of the needs for explicit closures in WYSIWYG > editors ;) Hey, it's not irony, it's sympathy. Ian ___ Webware-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/webware-devel
Re: [Webware-devel] async
Geoff Talvola <[EMAIL PROTECTED]> wrote: > Yes, there already is an HTTPServerAdapter -- it's called Apache + > mod_webkit :-) > > I think of HTTPServer as something you would use if you wanted to embed an > HTTP server into another application to provide a web-based interface to > that application without needing a separate web server. In some > circumstances this can be very useful. It's also convenient to use for > development since it's so easy to get started with it. For actual > deployment, I assume most people would go with Apache or another web server > to get the benefit of SSL and/or to be able to serve static files directly > from the filesystem. Well, I proposed HTTPServerAdapter more for the simplicity and ease of maintenance. If the only real reason for an HTTP server to be included with Webware is so that it can be embedded, doesn't HTTPServerAdapter fit that bill too? It's another process, but what's a few processes among friends? > >Also, eventually there *is* going to be a FTPServerAdapter... if > >someone else doesn't write it, I'm sure I will. With more than one > >server involved it's easiest if the AppServer is always expected to be > >in place. > > I didn't quite get this. Are you proposing writing an FTP adapter in > Python that would accept FTP requests and forward them to the app server as > though they were HTTP GET requests? HTTP is probably too minimal, but the basic socket communication with the AppServer could be extended with the FTP commands too. Say, by passing a dictionary with 'format': 'FTP', and whatever command set makes sense. I've only had a cursory look at what WebDAV does, but there seems to be a similar command set. Maybe FTP should be phrased in WebDAV terms. > I think rather than write more and more adapters I prefer to go with Chuck > and Tavis's goal of allowing the app server to listen on different ports > and different protocols. Maybe it's not important, but there seems to be a better symmetry to adapters. Webware doesn't (very successfully) implement any protocols directly right now, relying on adapters to do that. Is HTTP definitely unique in needing that abstraction layer? OTOH, something like FastCGI could perhaps be implemented directly in the AppServer, which would probably speed it up considerably. Ian ___ Webware-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/webware-devel
Re: [Webware-devel] async
Tavis Rudd <[EMAIL PROTECTED]> wrote: > On Wednesday 30 May 2001 11:50, Ian Bicking wrote: > > OTOH, something like FastCGI could perhaps be implemented > > directly in the AppServer, which would probably speed it > > up considerably. > > hmmm, interesting thought. So you'd use mod_fastcgi to connect > to the AppServer? I don't think it would be any faster as mod_webkit > is essentially doing the same job but is specifically optimized for this > usage scenario. True. I'd only use it if mod_webkit wasn't available. Right now I imagine that fastcgi is slower, because you are making a socket connection from the web server to the fastcgi adapter, and then another connection from there to the AppServer. I don't really know, though, since I only was able to briefly get fastcgi to work before I broke it again. It was all very frustrating. Basically it seems like fastcgi is doing the exact same sort of thing that the current adapter/appserver architecture does. Only fastcgi is more general, and not optimized with any particular language in mind. > Probably worthwhile investigating, but it would > require some work to get all the retry/restart stuff sorted out I'm kind of curious -- fastcgi starts up its own servers in some fashion. Whatever it does, it must be doing it robustly, since it's relatively widely deployed. Maybe it has a good technique that can be used for Webware, even if only in the abstract. Ian ___ Webware-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/webware-devel
Re: [Webware-devel] WebKit at WWW
Geoff Talvola <[EMAIL PROTECTED]> wrote: [...] > Except that on Windows you'll probably need to use CreateProcess instead of > system. That right there argues for its inclusion in a library. Okay, that's a good argument. A C-based Webware Adapter Compatibility Layer! Hehe. Anyway, I can imagine these functions in a library: * mashalling * opening a socket to the AppServer (with error codes) * sending data on the socket, perhaps (if this is different on Windows), I suppose handling the socket in general. * if it comes to exist: restart the AppServer (not a current feature, after all) * reading address.text (even though mod_webkit doesn't do this) C just isn't good at moving information around cleanly, so I don't think the entire process of sending the transaction over the socket can be put in the library. Not if you are going to stream POST data directly over the socket, for instance. This was my first socket programming exercise in C, and I don't do much C programming, so maybe there's cleverness I'm missing. But I don't think so. Ian ___ Webware-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/webware-devel
Re: [Webware-devel] cvs updates: Dynamic Number of Thread
Tavis Rudd <[EMAIL PROTECTED]> wrote: > On Monday 04 June 2001 07:41, Geoff Talvola wrote: > > I also argued that we'd be better off storing the threads > > on a stack instead of a queue. That way the most > > recently used threads get reused, which may produce > > slightly better performance. I wonder if there's a > > thread-safe Stack class analogous to the Queue class that > > comes with Python? > > Good idea. I've never heard of a Stack class like this but it > would be very easy to create a subclass of Queue that has > LIFO rather than FIFO behaviour. Do you think it would make > much of a difference? Well, what about .pop() and .append() ? If they are atomic, then they are thread-safe. Append is atomic, and I bet pop is too. But maybe there's spiffier things that the Queue class does that a Stack class could do too. Queue docs specifically refer to subclassing to make a Stack class. Ian ___ Webware-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/webware-devel
[Webware-devel] MK and XML
Thinking about XML, it occurred to me that representing MK models in XML might not be best -- it almost makes sense to put the models in the form of DTDs (though I don't know how explicit a DTD can be about details like ints/floats/dates/etc). Anyway, I was thinking about how a set of XML records is just like a (potentially complicated) relational database, and that the database description really maps to the XML description, which is a DTD. Now, moving between those two worlds (RDBMS and XML record) seemlessly... now *that* would be cool. hOpla seems to do something like this... http://hopla.sourceforge.net/en/ ... poorly documented, having a problem learning about it. 4suite has something too, DbDOM. Both seem to rely on Postgresql, not MySQL. Anyway, food for thought. Ian ___ Webware-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/webware-devel
Re: [Webware-devel] TS change request
Chuck Esterbrook <[EMAIL PROTECTED]> wrote: > Or insert: > #insert "foo.text" > All though that is a little vague and starting with "in" like "include" > might create brainspace competition. Forget "insert". #insert was the first thing I thought of, before reading your post. I think it's a good name. Verbatim is a hard word, and I'm not *really* clear what it means. Copy confuses me, because I think of that word with computers as a very active verb -- like, it does something external. Copyfile, perhaps, or insertfile. Just my $0.02 Ian ___ Webware-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/webware-devel
Re: [Webware-devel] TS change request
Tavis Rudd <[EMAIL PROTECTED]> wrote: > On Thursday 07 June 2001 10:39, Ian Bicking wrote: > > > Verbatim is a hard word, and I'm not *really* clear what > > it means. Copy confuses me, because I think of that word > > with computers as a very active verb -- like, it does > > something external. Copyfile, perhaps, or insertfile. > > I think people would learn it's meaning fairly fast as it's > also used in the #verbatim directive There's good > symmetry in that. Can you think of any easier words > that mean the same thing? > > as is > escaped > plain > noparse unparsed plain text text/plain (from MIME) raw raw text I think raw text makes the most sense to me. Plain text also seems like a good description. Ian ___ Webware-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/webware-devel
Re: [Webware-devel] TS change request
Tavis Rudd <[EMAIL PROTECTED]> wrote: > one other minor point: > should we require the quotation marks on files? Yes! Ian ___ Webware-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/webware-devel
Re: [Webware-devel] TS change request
Chuck Esterbrook <[EMAIL PROTECTED]> wrote: > But, yes, we can do without quotes. After all, $foo doesn't even expand > with quotes unless $foo really contains them. TS doesn't -- I don't think, at least shouldn't -- "expand" values. That way lies sh and m4, and those are scary. $foo *evaluates* to "file.txt", just like "file.txt" evaluates to "file.txt" -- that is, the textual representation is one thing, the internal representation is another. "file.txt" is a textual representation of the string "file.txt". $foo is a reference to the string "file.txt". Ian ___ Webware-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/webware-devel
Re: [Webware-devel] TAL component of ZPT in WebKit
Donovan Preston <[EMAIL PROTECTED]> wrote: > - You can access methods or data members of this page from your TAL like > this: > Dummydata > Where getContent is a function on your page object. Now, tal has some sort of path syntax, based more closely on Zope internals, right? So are you just using the python: escape for all your values? Ian ___ Webware-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/webware-devel
[Webware-devel] Notes on TAL
Just looking through TAL now. Pretty well partitioned from the rest of Zope, it seems. That's nice. Anyway, I thought I'd note that it works with HTML (not just XHTML) now. This means it also contains a parser for HTML. It looks better informed than any parser we have at this point. Even if we just snagged the general algorithm, and not the code, it would be a step up. Ian ___ Webware-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/webware-devel
Re: [Webware-devel] Notes on TAL
For ZPT see: http://dev.zope.org/Wikis/DevSite/Projects/ZPT/FrontPage For TAL, which is I think the primary part of ZPT: http://dev.zope.org/Wikis/DevSite/Projects/ZPT/TAL For a description of the syntax (probably the most interesting part): http://dev.zope.org/Wikis/DevSite/Projects/ZPT/TAL%20Specification%201.2 To look at the HTML Parser, download: http://www.zope.org/Members/4am/ZPT/TAL-1.2.1.tar.gz And look in TAL/HTMLTALParser.py Tavis Rudd <[EMAIL PROTECTED]> wrote: > Is there a page somewhere that provides an overview > of it? > > On Friday 08 June 2001 11:26, Ian Bicking wrote: > > Just looking through TAL now. Pretty well partitioned > > from the rest of Zope, it seems. That's nice. > > > > Anyway, I thought I'd note that it works with HTML (not > > just XHTML) now. This means it also contains a parser > > for HTML. It looks better informed than any parser we > > have at this point. Even if we just snagged the general > > algorithm, and not the code, it would be a step up. > > > > Ian > > > > ___ > > Webware-devel mailing list > > [EMAIL PROTECTED] > > http://lists.sourceforge.net/lists/listinfo/webware-devel > ___ Webware-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/webware-devel
Re: [Webware-devel] PlateKit
Geoff Talvola <[EMAIL PROTECTED]> wrote: > > > That would be fairly Pythonic in the same way that .pyc's > > > are handled. Especially if there were no complaints when > > > write access wasn't available. > > > >Hmmm, that sounds about right. So long as it also makes > >a backup of any existing .py files with the same basename. > > How about this instead: it only replaces the .py file if it was itself > autogenerated. The servlet factories could embed a I'm not entirely clear on how this part of TS works, but how about if SomePage.tmpl created a GenSomePage.py, and SomePage.py inherited from GenSomePage? SomePage.py would be automatically created if it doesn't exist, but it would be strictly boiler-plate... i.e., you can edit it without worrying that it would ever need to be regenerated. Kind of like how MK does this for models. Ian ___ Webware-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/webware-devel
Re: [Webware-devel] Notes on TAL
Chuck Esterbrook <[EMAIL PROTECTED]> wrote: > At 01:26 PM 6/8/2001 -0500, Ian Bicking wrote: > >Anyway, I thought I'd note that it works with HTML (not just XHTML) > >now. This means it also contains a parser for HTML. It looks better > >informed than any parser we have at this point. Even if we just > >snagged the general algorithm, and not the code, it would be a step > >up. > > What would make it better than HTMLTag? It's intelligent about paragraph-level, block-level, bigger-than-paragraph-level, and maybe some other stuff too. I.e., it knows that ends , for instance. Ian ___ Webware-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/webware-devel
[Webware-devel] More notes on TAL
In TAL, you use , which seemed verbose to me. But I believe you can change the default to python: by changine line DummyEngine.py:138 to 'type = "python"'. As it is, the path syntax is actually not in TAL at all -- paths seem to be implemented by overriding __getitem__ in the globals dictionary -- i.e., the access method for path: is the same as var:, local:, or global:. So it is quite reasonable to leave it as it is. In the future, I imagine TAL might be changed for performance reasons, e.g., compiling. But for now it's easy. I haven't actually tried putting it together in Webware with Donovan's code. But the whole package is really quite clean. Ian ___ Webware-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/webware-devel
[Webware-devel] Re: [Cheetahtemplate-discuss] Cheetah 0.9.4 atcheetahtemplate.sourceforge.net
Tavis Rudd <[EMAIL PROTECTED]> wrote: > I think we should aim for a 1.0 release with full docs and > a stable syntax for the end of July. Until then how about > we just keep on incrementing the 0.9.# numbers until we > think we're ready, then have a 2 week freeze period? The implementation can be easily changed after 1.0, but the syntax can't. Considering there's still lots of addition of directives, and changing of the semantics of directives, freezing it any time soon will mean a inelegant syntax with lots of vestigial constructs. One alternative would be to make TS more future-compatible, but versioning the input. I remember browsing some discussion on the Python lists. One person noted a system that had a version at the top the file, and would sometimes edit the code in-place or put in backward compatible features. This way the new syntax could delete things, while the old syntax could still work. Actually doing that support might be hard work -- but it's hard work you can put off for a while, because all that's required now is putting a version at the top. Anyway, I think you shouldn't even *talk* about a freeze date until you really know what you are working towards. I think that's still up in the air for both of the important parts of Cheetah -- the syntax, and the interface. 1.0 means these shouldn't change for a while. Ian ___ Webware-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/webware-devel
Re: [Webware-devel] Muliple Service AppServer
Chuck Esterbrook <[EMAIL PROTECTED]> wrote: > At 05:12 PM 7/22/2001 -0400, Jay Love wrote: > >Anyway, let me know if you can take a look at this. It will probably be > >easiest to just send out a complete tarball. > > How about just uploading that to the anon ftp area of Webware (sans .pyc & > CVS/ files)? I always forget how to do that, but then SF docs describe how. Didn't SourceForge eliminate anon ftp? Ian ___ Webware-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/webware-devel
Re: [Webware-devel] Muliple Service AppServer
Jay Love <[EMAIL PROTECTED]> wrote: > I also worry that this setup pushes the limit of using a dictionary as > the configuration file format. I messed up and forgot to include a > comma in places a couple of different times, and got cryptic errors > (well, they'd be cryptic to a regular user). BUT, if someone would > write the Web based configuration editing servlet, it wouldn't be as > much of a concern. ;) If the error messages are too cryptic, maybe it just means the reader should be more robust to give better messages -- especially the comma error, which is so common. I'm not sure how you could do a web based configuration editing servlet, because when you were halfway done you'd have broken the installation and couldn't access the servlet. If the reader is smarter, maybe we could make it check the extension (.config, .lineconfig, maybe just .conf...) and read based on that. Maybe it could use ConfigParser, but I don't think that supports any sort of nesting... shlex looks more general. Ian ___ Webware-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/webware-devel
RE: [Webware-devel] Path Based Session in WebKit
"Love, Jay" <[EMAIL PROTECTED]> wrote: > This will probably be easier than you think. We already have the code in > place to handle "extra path info" URLs. You just need to enable it in > Application.config, then parse the "extraURLPath" property of the Request > object. I suggest handling all this in HTTPRequest.sessionID(). You just > need to add a second place to check for the sessionID, in addition to > values(). I don't think extraURLPath will help him -- (my impression is that) he wants to use the current Servlet path mechanism, but with the SID at the root of that path. He'll have to subclass/edit Application in order to do this. In particularly, the serverSideInfoForRequest method. It would be good to factor this method better, as there's not many hooks for doing what he wants. There should be a serverSideInfoForRequestURI or somesuch that just takes a string -- then his subclass would just override that, strip the SID out, and call the superclass. As it is, there's just a heap of code he'll have to sift through :-( Ian ___ Webware-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/webware-devel
Tabs and spaces (was: Re: [Webware-devel] Request _pathContext Asa generalization of Path Session)
Chuck Esterbrook <[EMAIL PROTECTED]> wrote: > At 11:32 PM 8/11/2001 -0400, Clark C . Evans wrote: > > Sorry about that... but after monkeying around > > with my editor and stuff... I just plain give up. > > Why are you all using TABs anyway! *shudders* > > Because TABs rule. ;-) > > I shudder whenever I have to cursor through hordes of spaces as well as > give up extra RAM and hard drive space. I could understand the RAM and hard drive argument if it was 1982, perhaps. Anyway, if you want to cursor fast use Ctrl-left/right or somesuch. Any good editor has ways to navigate quickly. > Most people solve this problem by using a nice editor. I recommend > UltraEdit, BBEdit or emacs depending on your platform. Emacs causes all sorts of problems with tabs. The tab key in Emacs is overloaded to mean indent-as-appropriate, so you can't really be explicit. You can make it indent with tabs, but then it is a royal pain to edit files with spaces. Also, I don't really know any way to make it indent continued lines properly -- it puts in tabs to replace every 4 spaces, not just for the initial indent. So what looks like: a = b + \ c to me, looks like: a = b + \ c To someone with eight-space tabs. This makes my code look ugly, though at least it causes no syntactic errors. I won't tell you the horrors of trying to edit a spaced file with tabs on. A dumb editor like pico (i.e., one for which all files are plain text) doesn't care, and tabs are easy enough -- well, as long as you know what the current file uses... god forbid you edit some code and use a tab where spaces are called for or visa versa. If you do that you're asking for a world of pain. While all the other ASCII characters are pleasantly concrete, tabs are not -- they are vague and unreliable, doubly worse when indentation actually counts (i.e., Python). I wouldn't care so much about tabs vs. spaces if it hadn't caused me all the grief it already has -- and if that grief was not repeated everytime I work with non-Webware code (which is almost universally indented with spaces). Ian ___ Webware-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/webware-devel
Re: [Webware-devel] corrections to the Skunkweb FAQ
Tavis Rudd <[EMAIL PROTECTED]> wrote: > 3) You write: > "WebWare uses a threaded model. While in some ways makes > things simpler, it makes many things more complicated. > Also, because of the Python global interpreter lock, if you > have more than 1 CPU, WebWare won't actually use very much, > if any of the additional CPUs since only one thread can run > at a time. SkunkWeb uses a forking process model, which > makes resource sharing more complicated in certain > circumstances, it will fully utilize all available > processors,"... "so SkunkWeb scales better." > > All of this is true, but the final statement is unproven. > There are many factors involved and realistic benchmarks > are needed before such a statement can be made. In particular, in most instances the bottleneck will be on non-CPU resources. In that situation resource pooling may be more important than utilitizing multiple CPU's efficiently. Real performance will likely have to take into account the efficiency of the database, file system, and any other resources. Allowing those other resources to scale may very well be more important to allowing the entire system to scale, than is the CPU-scalability of one component (the respective python framework). Of course, that's all only a maybe -- real performance only is meaningful in context, and only really by way of benchmarking. Scaling is only a way of describing one attribute of that performance. Perhaps the asymptotic performance of Skunkweb will outperform Webware for load N (for large enough N). But down that road leads Mindcraft. -- Ian Bicking Colorstudy Web Design [EMAIL PROTECTED] http://www.colorstudy.com homepage: http://www.colorstudy.com/ianb 4769 N Talman Ave, Chicago, IL 60625 / (773) 275-7241 ___ Webware-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/webware-devel
Re: [Skunkweb-list] Re: [Webware-devel] corrections to theSkunkweb FAQ
Drew Csillag <[EMAIL PROTECTED]> wrote: > Another thing for SkunkWeb performance. You want to turn off > userModuleCleanup. If on, it clears out any modules that were loaded > during the course of processing the request, which in a development > environment is what you want since you don't want to HUP the server > every time you make a module change, but in a production environment, > it can be a significant performance hit. Oooo... we should do that in Webware too. That's much simpler than all the other techniques tossed around, but should still by a lot faster than OneShot. Ian ___ Webware-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/webware-devel
[Webware-devel] Cookie/redirect errors
The errors with cookies and redirect seem to come up fairly consistently. Maybe webware should print a warning when both the location and cookie headers are set, or whatever the circumstances that cause this (maybe just for temporary redirect?) Ian ___ Webware-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/webware-devel
Re: [Webware-devel] Tux adaptor
Jimmie Houchin <[EMAIL PROTECTED]> wrote: > I am wanting to use Tux for the front webserver for a website I'm > developing. > > It would be very sweet if there were a Tux Webware adaptor. I would be > interested in what kind of performance such would have. I don't want to seem like too much of a spoil sport, but I doubt it would make much of a difference. At this point with mod_webkit, I think the adapter overhead is pretty much negligable -- I think even the C CGI adapter is pretty close to negligable. Most of the time is spent in Webware/Python, constructing a response. Since Webware is (sensibly) optimized more for the complicated case -- where there is some processing going on to create a response -- the trivial case isn't so terribly fast (not bad or anything -- but probably an order of magnitude slower than the adapter overhead). Ian ___ Webware-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-devel
Re: [Webware-devel] Tux adaptor
[EMAIL PROTECTED] (Mike Orr) wrote: > I don't think he meant the speed of the adapter per se, but rather the > overall impact of using Tux instead of Apache. Tux is supposed to be > faster and resource-lighter for static files, which could make a > difference on high-traffic sites. Sorry, I didn't mean the adapter entirely, but rather the time spent not inside the AppServer -- i.e., web server, adapter, passing information on the socket. Tux-like optimizations of short cutting certain parts of that process might do something -- like having the web server forward requests to Webware, instead of talking with the AppServer and then passing the response on. But even then I don't know if there's a lot of time to be saved there. Ian ___ Webware-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-devel
RE: [Webware-devel] Tux adaptor
Tavis Rudd <[EMAIL PROTECTED]> wrote: > Serving static files > = > On high load sites it makes no sense to serve static files > from the AppServer. I feel we need to make it easier to > serve only dynamic pages from the AppServer and leave > static files from the webserver (Apache, IIS, Tux, > whatever). An idea I had for this would be an extension to the adapters -- allow a return message that was simply "send file X". Of course, the adapter has to be on the same computer as the AppServer, but that's usually the case -- there could be some non-adapter code for when that isn't the case, of course. I think this can be better than simply telling the web server to serve certain kinds of files, because it allows you to do complicated URL->filename mappings, and to implement your own security for file access. These situations have already come up on the list, and I could use this sort of functionality myself. Ian ___ Webware-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-devel
Re: [Webware-devel] Tux adaptor
[EMAIL PROTECTED] (Mike Orr) wrote: > On Sun, Sep 02, 2001 at 10:49:42AM -0500, Ian Bicking wrote: > > I think this can be better than simply telling the web server to serve > > certain kinds of files, because it allows you to do complicated > > URL->filename mappings, and to implement your own security for file > > access. These situations have already come up on the list, and I > > could use this sort of functionality myself. > > Much as I like having the web server serve static files, it is > incompatible with having Webware automatically supply the filename > extension. > > Also, even though alternative webservers are great in theory, in > practice most professional deployments will probably have to use > Apache anyway, because they need access to other Apache features > like allow/deny based on client IP, rewriting, virtual hosts, having some > virtual hosts on the same IP be Webware and some not, etc. Unless we want to > port all of these features to another webserver. I'm confused...? This would be more adapter-level. I.e., you send something like: serve-static: /var/www/some-file And the web server serves that file. I'm not sure, but maybe Apache already does this with local redirects... but that wouldn't work with files that weren't URL-accessible. This would potentially save some memory and socket bandwidth, since the contents of the file wouldn't have to be temporarily loaded into memory in the AppServer, tossed over the socket, and then displayed. Whether this makes any sense to do, I suppose depends on the resource usage of Apache serving a static file and Webware doing the same. Maybe Webware is fast enough. Maybe the conversation between the adapter/web server and the AppServer is really the drain. But, anyway, it's not a big change and it's fully backward-compatible. Ian ___ Webware-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-devel
Re: [Webware-devel] Tux adaptor
[EMAIL PROTECTED] (Mike Orr) wrote:
> And I'm confused by what you mean. I'm talking about having the
> webserver broker all requests, and then through mod_rewrite, AddHandler
> for *.py, or somehow, having it invoke Webware only for dynamic files.
> This is what Tux is designed to do, although it's not as infinitely
> configurable as Apache is.
Then I think we're just talking sideways at each other.
The level of performance that Tux tries to achieve is, well,
unimportant to me. Serving files at 100x the speed of my bandwidth is
not particularly useful.
But the basic idea of a lot of optimizations Tux does is sound -- like
I think it loads a file directly to the ethernet card, without ever
loading it in system memory. That specific optimization isn't what we
need -- but that sort of skipping of intermediate steps could be a
useful optimization.
In the same way, instead of loading the file, pumping it over a
socket, and having it put through the adapter on its way wherever, it
would be faster to just tell the adapter to serve up a certain file.
Now, the adapter might do this, but I'm sure it would be faster if an
adapter could tell Apache to do this itself -- I imagine such a call
exists.
I suppose the other notion in Tux is having an external server that
does the hard work, while Tux throws out static files really quickly.
That's fine for images, but that's about all I'd ever (ideally) serve
entirely statically.
> Anyway, if the webserver brokers all requests and passes only the
> dynamic ones on to Webware, WW never gets a chance to get its clean
> little hands (as opposed to grubby little hands) on the other requests
> to see if they could benefit from automatic extension-adding.
In my mind I was expecting the adapter (or Apache) to be otherwise
neutral in the process -- it would read the data from the file, so it
wouldn't require an extension or whatever.
That is, you'd have something like:
* User requests /doc/foobar
* Adapter hands this off to the AppServer.
* AppServer notices there's a doc/foobar.doc file.
* It starts up the proper servlet, which actually tests that the user
has permission to view this file. It decides the user does.
* The servlet calls something like, say,
response.sendFile('/path/to/doc/foobar.doc'). /path/to is not
something you could ever get to without Webware.
* The response object notes that the adapter can hand the send-file
command (old or remote adapters wouldn't be able to).
* The response sets the header 'Send-file: /path/to/doc/foobar.doc'.
* The adapter notices the header. It leaves all the headers as they
are, but ignores the body of the response that was passed.
* The adapters sends the headers and the contents of
/path/to/doc/foobar.doc to the user.
Now, mind, I'd probably want to do a redirect from /doc/foobar to
/doc/foobar.doc, because then the user will get a file with an
extension. For files you don't expect the user to download no
extension is fine.
> Finally, we haven't yet determined that HTTPserver or Tux can
> necessarily take over Apache's job of serving several NameVirtualHosts,
> some of which are served by Webware and others not, while maintaining
> the same performance for all sites that Apache does.
There's lots of reasons you'd keep Apache, but I don't think it's hard
to duplicate it functionality -- at least the subset that is
meaningful for Webware. SSI isn't important, for instance.
Virtual hosts are pretty easy, because all the needed information is
already passed. SERVER_ADDR (for IP-based virtual hosting) and
SERVER_NAME (for name-based) is all you need.
Ian
___
Webware-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/webware-devel
Re: [Webware-devel] FieldStorage and backwards compat with stringmethods, etc.
Tavis Rudd <[EMAIL PROTECTED]> wrote: > Fair enough, but that expose users of Webware and Python > 1.5.2 to bugs that have been fixed in the recent versions > of cgi.FieldStorage. With that in mind, is there any point > in trying to keep Webware compatible with Python 1.5.2? While Webware isn't all that easy to install in environments where you don't have root, it's even harder if you start requiring Python v2+. Almost all commercial hosts have v1.5.2. OTOH, almost all commercial hosts don't allow something like Webware. Ian ___ Webware-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-devel
Re: [Webware-devel] FieldStorage and backwards compat with stringmethods, etc.
Tavis Rudd <[EMAIL PROTECTED]> wrote: > Is anyone actually using Webware in a shared hosting > environment? Ian, weren't you looking around for someone > that would let you run it? No, I never really found anyone, though I didn't try incredibly hard. I'm sure there are those who would. I don't use 1.5.2 either. But I still mostly program to 1.5.2, maybe I should finally stop. Ian ___ Webware-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-devel
Re: [Webware-devel] FieldStorage and backwards compat with strin
Fionn Behrens <[EMAIL PROTECTED]> wrote: > I am using Webware with 1.5.2 and I am in the middle of a rather biggish > project I started last year. Because of the uncertain licensing issues we > decided NOT to use python 2.0. I know that this is solved now, but > I would prefer not to have to switch the python version in the middle of > everything just because Webware does. Maybe, when the project is finished, > I will adapt it to 2.0 but at the moment I have to stay on schedule with > development stages. FWIW, I've yet to encounter any backward compatibility problems with 2.0. Changing to Python 2.0 was amazingly uneventful. Ian ___ Webware-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-devel
[Webware-devel] Files of multiple extensions
Is it possible for Webware, as it currently stands, to pick one file over another by extension? In particular, I want .tmpl files to be picked over .py files (as the .py would be more or less generated from the .tmpl). It seems like this isn't possible now...? Ian ___ Webware-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-devel
Re: [Webware-devel] Path(method) problems continued (bug?)
Fionn Behrens <[EMAIL PROTECTED]> wrote: > > host is the server name, adapter is the, well, adapter (like /WebKit/ > > -- the portion of the path that leads to the AppServer)) and path is > > the path to the servlet. > > > > I.e., http://someplace.com/WK /SomeContext/page.psp > > [ host][adapter][ path] > > Well. What I wanted to point out is, that the function does NOT work like > you (and itself) describe it. What I got (didnt you see?) was: > >www.myadress.net/mydir/test.psp/opt/www/mydir/test.psp >[ host ][ adapter ][ path] > > which looks pretty unusable to me. Or have I missed a point? I hadn't looked that closely. Anyway, it seems like .urlPath() is giving you .fsPath(). There seems to be (in WebKit.HTTPRequest) a case where it does this for some adapters (that set WK_ABSOLUTE)...? I'm afraid I don't really know what's up with that. Geoff or Jay might know. I don't use PSP, so it hasn't come up. It may be with PSP, when you set a handler for it in Apache, that there isn't any adapter. SCRIPT_NAME gets set to the URL path of the PSP page and PATH_INFO is empty. HTTPRequest.urlPath seems wrong to return .fsPath, and .adapterName() should return '', at least in this case. But I'm just guessing. Ian ___ Webware-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-devel
RE: [Webware-devel] Bad cookies hang Webkit
Probably best would be to post it as a bug to
http://www.sf.net/projects/python
"Love, Jay" <[EMAIL PROTECTED]> wrote:
> Jeff-
>
> Please submit this bug to the Python-Devel list as well. I don't know the
> address, but they need to fix it in their source as well.
>
> Thanks for tracking this down.
>
> Jay
>
> > -Original Message-
> > From: Jeff Johnson [mailto:[EMAIL PROTECTED]]
> > Sent: Thursday, September 20, 2001 6:16 PM
> > To: Geoff Talvola; Love, Jay; [EMAIL PROTECTED]
> > Subject: RE: [Webware-devel] Bad cookies hang Webkit
> >
> >
> > Since I'm going on vacation as soon as I fix this problem, I
> > decided I'd better try again. I didn't write the crappy
> > cookie with the equal sign but my code has to deal with it...
> >
> > Here's a good fix for WebUtils.Cookie.py around line 518:
> >
> > # @@ JCJ - allow equal signs in the cookie value.
> > #_LegalCharsPatt = r"[\w\d!#%&'~_`><@,:/\$\*\+\-\.\^\|\)\(\?\}\{]*"
> > _LegalCharsPattKey=
> > r"[\w\d!#%&'~_`><@,:/\$\*\+\-\.\^\|\)\(\?\}\{]*"
> > _LegalCharsPattValue =
> > r"[\w\d!#%&'~_`><@,:/\$\*\+\-\.\^\|\)\(\?\}\{=]*"
> > _CookiePattern = re.compile(
> > r"(?x)" # This is a Verbose pattern
> > r"(?P" # Start of group 'key'
> > ""+ _LegalCharsPattKey +""# Any word
> > r")" # End of group 'key'
> > r"\s*=\s*"# Equal Sign
> > r"(?P" # Start of group 'val'
> > r'"(?:[^\\"]|\\.)*"'# Any doublequoted string
> > r"|"# or
> > ""+ _LegalCharsPattValue +""# Any word
> > r")" # End of group 'val'
> > r"\s*;?" # Probably ending in a semi-colon
> > )
> >
> >
> > > -Original Message-
> > > From: [EMAIL PROTECTED]
> > > [mailto:[EMAIL PROTECTED]]On Behalf Of Jeff
> > > Johnson
> > > Sent: Thursday, September 20, 2001 5:50 PM
> > > To: Geoff Talvola; Love, Jay; [EMAIL PROTECTED]
> > > Subject: RE: [Webware-devel] Bad cookies hang Webkit
> > >
> > >
> > > Well, I found the person with the bad cookies. The offending
> > > cookie is
> > > has two equal signs in it! Is that legal??
> > > "WWWLYCOS=SATISFACTIONSURVEY=N;"
> > >
> > > Does anyone have a suggestion of how we can handle this exception
> > > gracefully or improve the parser?
> > >
> > >
> > > I printed out the offending cookie and the exception below.
> > >
> > > lubid=01508BD3046104E43BAA159C000AC846;
> > > WWWLYCOS=SATISFACTIONSURVEY=N; _SID_=2001092017242334450;
> > > countyno=127;
> > > state=FL; city=Barberville
> > >
> > > Traceback (most recent call last):
> > > File "/usr/Webware/Webware/WebKit/HTTPRequest.py", line 47, in
> > > __init__
> > > self._cookies.load(self._environ['HTTP_COOKIE'])
> > > File "WebUtils/Cookie.py", line 605, in load
> > > for K,V in self.items():
> > > File "WebUtils/Cookie.py", line 625, in __ParseString
> > > n = len(str) # Length of string
> > > IndexError: string index out of range
> > >
> > > ___
> > > Webware-devel mailing list
> > > [EMAIL PROTECTED]
> > > https://lists.sourceforge.net/lists/listinfo/webware-devel
> > >
> >
>
>
>
>
> This e-mail and any attachments may be confidential or legally privileged.
> If you received this message in error or are not the intended recipient, you
> should destroy the e-mail message and any attachments or copies, and you are
> prohibited from retaining, distributing, disclosing or using any information
> contained herein. Please inform us of the erroneous delivery by return
> e-mail.
>
> Thank you for your cooperation.
>
>
>
>
>
> ___
> Webware-devel mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/webware-devel
>
___
Webware-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/webware-devel
RE: [Webware-devel] Terminals and Output
nohup will only redirect output to nohup.out if you haven't redirected it yourself, and then I believe only if you actually print something to stdout. Maybe try running python with "python -u", which should turn off buffering. "Jeff Johnson" <[EMAIL PROTECTED]> wrote: > I was almost content to let the 1024 byte string printing problem go and > just never print big strings to stdout. That worked for a few hours. > Then we noticed the servlets were hanging again. Turns out that the > traceback from a simple syntax error was 1381 bytes long and hung the > servlet when it tried to print the error. > > When I search google for "stdout 1024" I see a lot of stuff. I see some > stuff about Perl and turning off buffering. Maybe this could be done in > Python? > > The nohup command looks promising but it doesn't seem to do what the man > page says it does. It says it will redirect output to "nohup.out" but > those files are not created and I still see output on my terminal. Any > ideas? I tried "nohup ./AppServer daemon". > > Jeff ___ Webware-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-devel
RE: [Webware-devel] Terminals and Output
"Jeff Johnson" <[EMAIL PROTECTED]> wrote: > > nohup will only redirect output to nohup.out if you haven't redirected > > it yourself, and then I believe only if you actually print something > > to stdout. > > I'm not redirecting stdout so it should but it doesn't. I can't get > nohup to do much of anything. According to the short manpage, I would > think "nohup ls" should create a file nohup.output with a directory > listing in it, it doesn't, it goes to the console. Strange. If it can't write to nohup.out, it writes to ~/nohup.out -- maybe that's it? Ian ___ Webware-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-devel
RE: [Webware-devel] Terminals and Output
"Jeff Johnson" <[EMAIL PROTECTED]> wrote: > > Webware is now eliminated. Can we eliminate Python? eg., what > > about bash or perl? > > I don't know shell scripting but I might be able to remember enough perl > to try that route. echo '' (1024 x's) Ian ___ Webware-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-devel
Re: [Webware-devel] MiddleKit thoughts
Chuck Esterbrook <[EMAIL PROTECTED]> wrote: > In direct answer to your question, yes I have projects where multiple > clients hit the database, but no they are all MK. (Unless you count the > MySQL GUI that I sometimes use to fix things up.) If you turned off caching (I'm not sure how this would work in MK), and you used the ad-hoc-foreign-key trick, would MK work with stock schemas and with multiple (non-MK) clients? Ian ___ Webware-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-devel
Re: [Webware-devel] pathVariables
"Clark C . Evans" <[EMAIL PROTECTED]> wrote: > | In fact, what's apparent from previous discussions is > | that URL-needs vary widely. > > This isn't clear to me at all. What other requirements > would there be? I can see one other requirement -- one > would like to use path based syntax instead of query > parameters; much like Java Servlet path mechanism. This > is a completely separable requirement from the one above. > And a single solution will most likely not satisfy both. Oh, there's much, much more that can be done with URLs. For instance, I'd like to be able to join two directories -- one which contains servlets, and one with contains static pages or perhaps Cheetah templates. A nonprogrammer would then be insulated from documents which would be dangerous to edit (Python code). I'd like to properly represent abstract objects (like database objects). I can do this with extraPathInfo now, but the caching doesn't work as I'd want -- I have to recreate the servlet each time on awake(), when if the servlets were cached according to that extraPathInfo (or something like that), then I'd only have to set things up in __init__. I'd like to be able to modify settings based on the path of the URL. For instance, .html files in some paths might need to go through a processor that wraps them in a template -- in other paths they might be presented verbatim. In some paths, errors should be emailed to me, in other paths they should be displayed immediately. I'd like to be able to better be able to resolve conflicts between extensions. Specifically, I'd like to be able to say that .tmpl files override .py files. I'd like to do positional arguments before the servlet -- perhaps fragile, but also traditional and a bit more compact. Somewhat like mod_speling, I'd like to have case-insentive URLs and I'd like to have spell checking in the URLs -- including spell checking on non-filesystem arguments (positional URL arguments both prefixing and following the servlet name). I'd like to have enough introspection to create a sitemap directly, as well as indexes and the like. I'd like to be able to represent arbitrary URL mappings, ala mod_rewrite. That's just a few things I can think of, mostly things which I can give specific situations where I'd use them. I bet other people will have other ideas. I *don't* think that Application should support all of these -- quite the contrary. I'd like to see a system that gives all the *hooks* necessary to do these sorts of things. I'd like a less centralized algorithm -- much shorter than what is currently there. The one things that I *don't* particularly want is fully dynamic URL mapping -- I'm fine with indefinitely caching the results of a URL decoding. Those results won't necessarily be a filename, but they'll be something. > In short, I only see two core permutations: > > 1. The query information comes *before* the servlet, > and hence is shared across multiple servlets. > This is my case, and the case of the path based > session mechanism. > > 2. The query information comes *after* the servlet. > And hence is specific to a specific servlet. > This case is a simple rewrite of query parameters. > > There are two sub-permutations: > > A. The parameters are by position. This is much like > The java servlet mechanism. And this exposes either > an array for the parameters or a lookup table is > needed to mix these parameters with the query parms. > > B. The parameters are named by a key. This is much > like the http query parameter mechanism. > > What I need is B1. The built-in http query parameters > give you B2. I don't think A1 or A2 are that useful > since parameters by position is brittle and not self > documenting. And I would put forth that perhaps > given B1 and B2, A1 and A2 are not necessary. Quite the contrary, I don't mind passing every URL through a function, so B1 and B2 don't seem very useful to me, since query strings are generally fine for that sort of thing. Ian ___ Webware-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-devel
Re: [Webware-devel] pathVariables
Chuck Esterbrook <[EMAIL PROTECTED]> wrote: > At 12:10 AM 10/25/2001 -0500, Ian Bicking wrote: > [snip several examples] > >That's just a few things I can think of, mostly things which I can > >give specific situations where I'd use them. I bet other people will > >have other ideas. > > I don't know Ian. I think you might have covered it all. ;-) Oh, I forgot one! Do the thing that Zope does, where when you should have a url like /path/to/something and it should be /path/to/something/, see if the servlet can handle that on its own (by putting in the output), or if you should do a client redirect, or if you should just ignore it (for instance, if you are serving a non-href-aware type of document). Ian ___ Webware-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-devel
[Webware-devel] Bug in file upload
Well, not *exactly* a bug. Anyway, if you upload a large file and get an error message, the entire contents of the file shows up in the "fields" section, which makes for a lot of garbage to download. It seems better to only print out the first, oh, maybe 500 characters of each field. Ian ___ Webware-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-devel
Re: [Webware-devel] [Announce] LoggingKit 0.1.0
A few thoughts: A mixin would be nice, so that the instantiation is a little easier, and you could just do self.info(...) (or maybe self.logInfo(...)) It would be nice to incorporate the current (casual) logging, which is basically all printing to stdout/stderr. Redirecting these into LoggingKit mechanisms would keep things centralized. Oh, and I noticed a few tabs mixed in with the spaces in the source. Sascha Matzke <[EMAIL PROTECTED]> wrote: > Hi, > > back in May I met Tom Schwaller at a local Java conference here > in Germany. He told me about the Webware project and so I played > with it a little bit and was instantly interested. One thing I was > missing back than was a configurable, flexible logging approach. So > I decided to try to implement such a solution. > > And here it is... > > LoggingKit version 0.1.0 > > If you want to try it you can download it at > > http://www.scourbase.de/LoggingKit-0.1.0.tar.gz > > Some preliminary documentation and a basic unittest are included > in the tar-file. > > Sascha > > > ___ > Webware-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/webware-devel > ___ Webware-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-devel
Re: [Webware-devel] UserKit
Geoff Talvola <[EMAIL PROTECTED]> wrote: > That reminds me of something I meant to bring up a while ago. Session IDs > are currently not very random. Only the last 5 digits are actually random > -- the rest of it is just the current time expressed as a string. > > This could be a security hole in that it makes it not too hard to guess the > session ID and take over a session. Well, if you also used IP number in the session, you'd make it much more secure. Potentially a malicious snoop could intercept the HTTP requests and get the cookie, no matter how random. But it's considerably more difficult to get the cookie and impersonate or intercept the IP address. Simply guessing the session ID wouldn't provide anything, either, since again it's quite hard to fake an IP address effectively. The only disadvantage is for people on dialup, if they redial they will probably get a new IP address and will have to start a new session, even if they never closed their browser. A more complete solution might be, in secure situations, to have some way of intercepting a good session with a bad IP, and require relogin to restore their old session. Or, right now, you store their IP number in their session, and give a warning if it changes. Then if there's an imposter online at the same time as the real user, the real user will keep getting warning messages and hopefully realize something's wrong. Actually, now that I think of it, all of this is easily doable without changing Session itself, but just how you use it. Ian ___ Webware-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-devel
Re: Session Ids [was Re: [Webware-devel] UserKit]
Geoff Talvola <[EMAIL PROTECTED]> wrote: > I could write a program that keeps on trying random session IDs with the > date/time part of the session ID set to a couple of minutes ago, so the > session is likely to still be around. It might take hundreds of thousands > of tries but it would eventually find a valid session ID, especially on a > site that gets a lot of traffic and therefore has a lot of new sessions > getting created all the time. OTOH, if you have a lot of traffic, the security for the bulk of those users probably isn't a big deal. Maybe Hotmail has to worry about this (a bit), but few other sites. Usually there's only a relatively small number of people who have enough privileges to matter much. Simply distributing the passwords to large numbers of users is very insecure anyway. Self-registration implies that the user has built their privilege up after registration -- usually by creating some sort of content afterwords. This is how I'd classify Hotmail. Things like credit card numbers -- easy to put on the site, highly privileged -- should really be deleted anyway. I still can't believe my fucking bank thinks my social security number is a good enough form of authentication. Or worse, just the last four digits. It's a goddamned disgrace. So while we might think "except for banks, this should be good enough" banks think even less security is good enough. Ian ___ Webware-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-devel
Re: [Webware-devel] UserKit
Baruch Even <[EMAIL PROTECTED]> wrote: > If someone can sniff out your session, he can easily fake the TCP/IP > connection with ease. Really? I understand how sniffing works (though with proxies there's potentially other ways that cookies can be spied on), but I don't really know how IP address are spoofed. Without control of the routers, wouldn't the return traffic end up going to the right subnet no matter what, and wouldn't the correct computer at least try to respond, even if another computer tried too? I'm not entirely clear on how TCP/IP connections are made, though, so I might be missing something there. MAC addresses have to come in there somewhere too, if I remember correctly, but I've forgotten where. After reading your article, a non-SSL solution occurred to me. You can implement MD5 on the client through Javascript (see http://pajhome.org.uk/crypt/md5/md5src.html), and it's not even a very long bit of code. It should be easy to send the salt as a hidden field in the form, then onSubmit do a bit of code to hash the password with the salt and delete the plaintext password. This only works with Javascript-enabled browsers, but that's most people. Especially for privileged users, you can demand they use such a browser (not a big deal). I'm not sure how to make sure the user doesn't accidentally send their plaintext password when they don't have Javascript, except to have a gateway page that uses the Javascript code to preauthenticate in some manner. Though if you don't name the password field, and use document.forms.someform[number] to access it, then I suppose it's private to the browser...? Ian ___ Webware-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-devel
RE: [Webware-devel] Live webware site :)
Chuck Esterbrook <[EMAIL PROTECTED]> wrote: > I just never really understood the anti-cookie movement. I investigated it > at one point by reading through archives and visiting anti-cookie sites but > never found a compelling, *concrete* example of why cookies were evil. The only cookies I really don't like are doubleclick.net cookies (or similar ad-based cookies). I think those are all bad, bad, bad. Just about all that is required to stop those is not allowing cookies on images, though, and browser-makers have firmly not stepped up to the plate on that, but I can't say I'm surprised. Like many privacy and general browser-control issues, the granularity of options is too poor for users to have control. Turn options off, and get cut off from the web. Leave options on, and get no protection. Ditto with popups (though Mozilla has just put in an option not to allow popups onLoad or onUnload, bless their hearts). Ian ___ Webware-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-devel
Re: [Webware-devel] Live webware site :)
Hey, just logged in. Looks real nice. It's great to see a well-branded live site with Webware! The error messages in the registration form were intermittent -- while many fields may have errors, only one or two at a time would display. All appropriate error messages should display at once if you're using FFK...? The membership account number is kind of odd -- and harder to type in since it's a password field. I'd just make it a plain text field -- there's nothing that secret about it, since it's assigned and printed in view on the signup page. Took me a second to realize all the under-$10,000 properties were empty lots. I was hoping for a really great deal :) It would be neat to link to a map based on the address. You have height/width tags on the house images, but the actual images' size doesn't match. Makes it out of proportion, and you can get weird dithering on some images. It would be best to make a constant-size thumbnail, with good interpolation, and then have it be a link to a popup of the full image. Sorting would be nice, since it's otherwise hard to find properties. There's 10 pages of results in my county, with a very wide range of properties. Sorting on how close they are to the target zip would be nice too. Crime represented in percentiles (vs. city, state, county, nation) would be much more helpful. Looks like you just have city, so make that vs. state, county, nation. There's a problem with the data, because Chicago must have at least one case of forcible rape, but None is listed. City search didn't seem to work -- just gave me the county results. "Jeff Johnson" <[EMAIL PROTECTED]> wrote: > We went live today with one of the sites we are working on. I didn't > expect to go live today but it was either that or wait a month so we > pushed ahead. Hopefully it works as expected :) > > http://foreclosures.lycos.com/ > > This is running FreeBSD, PostgreSQL, Webware, Cheetah and FunFormKit. > > Any suggestions appreciated. > > Jeff > > > ___ > Webware-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/webware-devel > ___ Webware-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-devel
Re: [Webware-devel] understanding the sources??
Well, you might want to look at a document I wrote up a while ago: http://207.228.250.44/software/webware/Anatomy.html I wrote it while I was trying to do pretty much what you are trying to do. It can be a little confusing to figure out just what gets called where. markus jais <[EMAIL PROTECTED]> wrote: > hello > > I would like to understand the sources of webware > can anybody give me a hint, with witch file/module to start?? > > thanks in advance > regards > markus > > -- > Markus Jais > http://www.mjais.de > [EMAIL PROTECTED] > The road goes ever on and on - Bilbo Baggins > > ___ > Webware-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/webware-devel > ___ Webware-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-devel
Re: [Webware-devel] print "." in ThreadedAppServer
Geoffrey Talvola <[EMAIL PROTECTED]> wrote: > Or, it could be made a config setting, so we're covered when the > same problem shows up on another OS. While we're at it, we ought to > add a config setting to suck up stdout and stderr to avoid the > _other_ FreeBSD problem Jeff reported. The possibility should also be considered that this isn't a FreeBSD problem, but a problem of running Webware in daemon mode, under normal production conditions. Jeff may very well be the only person doing that under significant load. I've been running Webware as a daemon happily under Linux, but only with insignificant load. Ian ___ Webware-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-devel
Re: [Webware-devel] webware daemon worries
Just "kill `cat appserverpid.txt`". I think that default is TERM (15). "Aaron Held" <[EMAIL PROTECTED]> wrote: > >> I read the code and I assume that > >> kill -9 `cat appserverpid.txt` > >> has the same effect as ./Appserver stop > >I wouldn't use the "-9", it won't clean up properly. > > What is the right signal? > > -Aaron > > > > > > ___ > Webware-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/webware-devel > ___ Webware-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-devel
RE: [Webware-devel] print "." in ThreadedAppServer
"Jeff Johnson" <[EMAIL PROTECTED]> wrote:
> The print "." fixed the problem where the socket took 30 seconds to
> after shutdown before the port could bind again. No load required, I
> just start, stop, attempt restart which would fail with a socket bind
> error. Not even in daemon mode.
You're right, I did get this in Webware when I did a quick
start/restart... it was more around less than 4-5 seconds, though it
was unpredictable.
OTOH, on another box where I have a daemon script, I put in this code
for shutdown:
stop)
echo -n "Shutting down WebKit: "
kill -s 2 `cat $PID_FILE`
for SUBPID in `ps aux --cols 200 | grep 'python Launch.py' | awk
'{print $2}'` ; do
kill -s 2 $SUBPID > /dev/null 2>&1
done
success "Shutting down WebKit"
echo
;;
and I haven't had any problem. Otherwise it simply wasn't killing all
the processes, or threads, or whatever they were. There's actually
only one of the "python Launcy.py" processes that needed to be killed
(after which all of the others were killed)... but it wasn't happening
before I did this.
I typically restart this daemon rather quick (just webkit restart,
which takes around 2 seconds maybe), and haven't had a problem since I
changed this.
Ian
___
Webware-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/webware-devel
Re: [Webware-devel] MiddleKit thoughts
Jack Moffitt <[EMAIL PROTECTED]> wrote: > MiddleKit seems to be very easy when you don't to worry about the > database details. But when you have a storage system already in place > and need the middle objects, it doesn't really help. Do you have to access that storage from different programs? If not then you could just transfer the information to the new (slightly different) database structure. Still, I've been reluctant to use MK myself because of this problem too. In part because the data (at least sometimes) is more valuable than the program. But the other part is I like the concept of a database as a means of abstraction and communication. Not only doesn't MK deal well with legacy databases, I don't think it would deal well at all with non-MK clients accessing and updating the database. At least that is my impression, as MK does a lot of caching. The database does caching itself, and personally I'd rather keep the caching flat -- caching at the Python level saves some communication overhead, and also caches what calculations occur to create the Python object (which should really be small anyway)... but if you are allowing multiple clients then that's going to kill any benefit of caching. I'd be curious just how much faster caching makes the database access in the current case. So, if MK is the moderator through which all requests have been made, is it as good a moderator as the database itself? It uses Python, which is nice, but maybe also not nice (if you ever have to use anything else). I'm not sure how well it would deal with all the potential data integrity problems -- these have taken databases a long time to resolve, and I think the entire work would have to be duplicated in MK to manage that integrity. Anyway, that's where I am myself. There's other similar things to MK, but most of them are lame dictionary interfaces (which capture the easy 90% of the problem, but just make the other 10% of SQL queries more awkward). I've looked at PyDO a little myself (it's part of SkunkWeb), but haven't come to any opinion. The author talks about some of these issues more or less in the intro to PyDO. In the end, I don't think the decision has to be made too firmly, if the *interface* of the objects you create is a good one -- be it with MK, PyDO, ad hoc, whatever. Then you could hopefully transfer it to something else. I've been thinking about how to shoehorn other document styles into Cheetah, and I realized that's dumb -- Cheetah doesn't have to support everything, but Cheetah exposes a certain interface and the interface I create for other documents should just match that. The same thing might make sense for legacy databases and MK. You don't have to use MK, you can just make something that looks like MK. Maybe there's also portions of MK that you can still use, just not the package as a whole. I've had the idea of my own wrapper in my head myself for a while -- but then I've had lots of ideas in my head, and that doesn't necessarily mean much. It's a hard problem. Ian ___ Webware-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-devel
Re: [Webware-devel] MiddleKit thoughts
Ian Bicking <[EMAIL PROTECTED]> wrote: > Anyway, that's where I am myself. There's other similar things to MK, > but most of them are lame dictionary interfaces (which capture the > easy 90% of the problem, but just make the other 10% of SQL queries > more awkward). I've looked at PyDO a little myself (it's part of > SkunkWeb), but haven't come to any opinion. The author talks about > some of these issues more or less in the intro to PyDO. I should ammend that and say that I don't actually think every dictionary access wrapper is "lame"... they deal well with a certain class of problems, usually where a database is treated like a fancy flat-file data store. A lot of problems only call for such a data store. But I have yet to see the system that lets you express a left join in any reasonable way. Honestly, I'm not even sure what it would mean to do a left join in MK or a similar product -- they rely on doing the queries mostly in Python, in an imperative fashion as opposed to SQL's declarative fashion. But I think SQL exists for a reason, and I just wish there was a way to mirror that functionality in Python. I want macros like in Lisp. I'm thinking of decompiling compiled Python functions into SQL :) In a way that's what SQLBuilder does -- but that's only a peripheral part of what I'm thinking of (and, I would expect, it's usable in MK or anything else that allows arbitrary clauses). Ian ___ Webware-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-devel
Re: [Webware-devel] SpacesNotTabs debate raging on comp.lang.python
Google has changed their interface -- that new tree view is quite nice. Especially the little orange bar to indicate where in the thread you are. I haven't seen that before. ___ Webware-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-devel
Re: [Webware-devel] SpacesNotTabs debate raging on comp.lang.python
On Fri, Dec 07, 2001 at 01:38:52PM -0800, Chuck Esterbrook wrote: > Okay, on more positive note without getting into flamewars again, I > have been thinking the following, but need help from emacs users in the > answers: > > - Recently, I saw a text file where someone included special comments > that apparently emacs picked up automatically and used for > configuration. Is that possible? Yes, there are some ways you can define Emacs settings on a per-file basis. I can't remember the syntax, but you put it in a specially-formatted comment in the file. It would have to be in all files, I don't believe Emacs picks up configuration files otherwise. I've also found that as long as I leave the tabwidth at 8, the auto-tab-detection works correctly -- i.e., Emacs inserts tabs in files that use tabs, and spaces in files that use spaces. I don't know why it doesn't work with a tabwidth of 4. This isn't pretty, lines wrap poorly, but at least I don't break code that way. The '''-quoted doc strings are still also a problem for Emacs. Ian ___ Webware-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-devel
Re: [Webware-devel] SpacesNotTabs debate raging on comp.lang.python
On Fri, 2001-12-07 at 18:58, Chuck Esterbrook wrote:
> On Friday 07 December 2001 02:30 pm, Ian Bicking wrote:
> > I've also found that as long as I leave the tabwidth at 8, the
> > auto-tab-detection works correctly -- i.e., Emacs inserts tabs in
> > files that use tabs, and spaces in files that use spaces. I don't
> > know why it doesn't work with a tabwidth of 4.
> >
> [snip]
> >
> > The '''-quoted doc strings are still also a problem for Emacs.
>
> Psuedo-radical thoughts:
>
> - Since emacs' auto-tab-detection almost works except when tabwidth is
> 4, would it be possible to fix emacs?
Probably. Since the autodetection works fine, and all of my own code
uses 4 spaces, I'm not as concerned. Not enough to go browsing through
the elisp looking for a bug -- and probably one that's subtle, since it
interacts with something deep in Emacs (the width that tabs are
displayed at).
> - Since emacs already handles multi-line strings with double quotes,
> would it be possible to fix it to handle multi-line strings with single
> quotes?
Double quotes work the same as single: the difference is that single
quotes are often not matched inside a doc string, e.g., '''don't use
this'''. Changing ''' to """ should be easy, and it pretty much fixes
this.
> > * Absolutely wrap lines before 90 (particularly docstrings). The
> > current codebase is absolutely full of run on lines.
>
> Hmm, I'm inclined to let code lines run a little longer, say 130. We
> presumably all have wide windows when doing serious development and
> most editors allow wrapping or non-wrapping as you like.
I use 80-columns. It's leaves me just a tiny bit shy of being able to
have two windows side-by-side. 80 is conventional. Most lines easily
fit in under 80, so if you use 130 you're just going to have a lot of
empty space on your screen.
In an endline-sensitive language, wrapping *can't* be as pretty as
manually putting in newlines -- if it was, you wouldn't be able to tell
that there were semantic differences in some instances. In the case of
Emacs, wrapped lines get cut off at exactly 80 (or whatever width your
window is), without any attention to word boundaries. I imagine lots of
editors are the same -- and if they *aren't* like that, I'd be afraid of
damaging my code by not realizing where the newlines were.
> > * Include a blank line before and after every docstring. This makes
> > it much easier to re-wrap the docstrings when the content changes.
Even in my own code, I usually insert the newline, wrap, and remove it
again, despite the inconvenience. I don't like having excessive
vertical whitespace -- M-Up and M-Down work better if you have just the
right amount of whitespace.
> > * If a method of function has lots of args list them one or two
> > per-line, instead of having a huge run-on line.
>
> Does "lots of args" mean past a certain column number or what?
I think there's a justification for long lines when you are doing lots
of composition of functions or something -- at least indenting the way
Emacs does, it is often no advantage to split lines. But when you have
lots of arguments it's really easy to split lines, so why not?
e.g., this will often go over 80 columns and is hard to fix:
self.myInstanceVar =
self.namespace().getVar(self.findVarName(self.request().field('fieldName', None
Some might say temporary variables are called for, or it's bad
programming style... but I tend to do this sort of thing quite often,
and there's no decent way of splitting that line to shorten it.
Ian
___
Webware-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/webware-devel
Re: [Webware-devel] SpacesNotTabs debate raging on comp.lang.python
On Sun, 2001-12-09 at 10:13, Chuck Esterbrook wrote: > In general, I'm not seeing that tools are designed around the > assumption that text files stop at 80 columns. > > In all three products, sizing the window to be wide enough for 130 > characters actually felt excessive to me, but 110-120 felt fine. I have > 19" monitor with 1152x864. > > The thing of it is, using editors that allow me to not wrap, I don't > really care how long some code lines go on. Should we even dictate that > code lines _must_ be wrapped at a column width? Is this another > emacs-only issue? > > Feel free to speak up. But if we decide "yes", it will be something > bigger and more modern than 80. I don't think lines shouldn't be *allowed* to go over 80 columns -- it happens sometimes, and sometimes it isn't easier to read the code just because you've arbitrarily put in some newlines. Consistency is the hobgoblin of small minds and all that. However, I think 80 columns is conventional, and generally appropriate. I don't *want* to make my editor wider than 80 columns, because that is a waste of space. I have better things to do with the rest of my screen than sport a bit chunk of whitespace for that minority of lines that go long. Choosing something other than 80 columns seems arbitrary. 80 is the convention for most code and email. As a result, I will *not* set up my environment for Webware code to the detriment of all the other code I work with. I will not make my font small, or my windows wide. I will not change whatever setting it is in Emacs that controls how wide the wrapping command works at. And why should I? And not just me, but everyone else? There's *nothing wrong* with standard Python conventions! Why can't we just use those? I am going to keep writing my code pretty much to Python coding standards, because I think that is the Right Thing -- not necessarily because those standards are the best, most logical, or most aesthetic standards. I'm going to do that because that makes my code most accessible to the general Python community, and means my code will fit in with most code from other sources. I'm going to set up my editor and general environment to do that. This shouldn't be a controversial choice. A lot of other people have chosen that too... and when they do, Webware code looks ugly to them. Instead of asking us to change our environments, shouldn't Webware just go along to get along? It seems like hubris to do otherwise. Ian ___ Webware-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-devel
Re: [Webware-devel] SpacesNotTabs debate raging on comp.lang.python
On Sun, 2001-12-09 at 13:00, Chuck Esterbrook wrote: > Scaling everything down to the most extreme people (the guy using an 80 > column terminal who prints and e-mails all of his code) hurts for those > who aren't (those with the space, the friendly editor and the > inclination to use them). Whereever you draw the line, someone is > gaining and someone is losing. That's where the constroversy comes from. > > Also, instead of changing how I code in Python, shouldn't editors like > emacs do the right thing? Python is the first language I've used where > I was expected to cater to a single editor (and one with source) > instead of expecting the editor to handle the language's text files. > That seems like hubris. > > You say "no, I won't do this and I won't do that for your source", but > then expect me to say "yes, I'll do this and I'll do that for one > problematic editor". That seems unbalanced. I am saying you should do these things because they are compatible with the dominant style in the larger Python community. I set up my environment to fit with those conventions -- perhaps it isn't a flexible enough environment for you, but as long as code stays more-or-less within those basic conventions my environment works quite well for me. If all Python code used tabs, then I could set up Emacs to use tabs just fine too. When I have to go back and forth it becomes problematic. By going against the dominant style, you force me to choose how I will set up my environment. When I spoke of hubris, I was refering to this: making someone choose between Webware and almost all the other Python code out there. When I was first using Webware, I actually did try to stick to guidelines. I changed Emacs so it would do tabs by default. I even converted a fair bit of my own code. But I eventually went back, because then it was annoying when I was editing code from other sources. The result is it's fine for me to edit other code, but annoying for me to deal with Webware code. It also means that packages designed specifically for use with Webware -- Cheetah and FunFormKit -- are not going to be written to Webware style guidelines. There are reasons I like 80 columns and spaces for indentation. But really, that's not the important issue. If a concensus had grown to do these things otherwise, I would not complain and I would adapt the configuration of my tools. For big issues -- like whether to have all attribute access be through functions -- the arguments for it are significant. I happen to agree with it -- but even if I didn't, I'd be able to understand that any incongruity with other code was for a real purpose. It's because these small style issues are so small that they seem more annoying. Really, no justification for or against them seems to stack up against convention and compatibility. Ian ___ Webware-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-devel
Re: [Webware-devel] SpacesNotTabs debate raging on comp.lang.python
On Sun, 2001-12-09 at 15:18, Chuck Esterbrook wrote: > On Sunday 09 December 2001 02:24 pm, Tavis Rudd wrote: > > On Sunday 09 December 2001 12:58, Chuck Esterbrook wrote: > > > I wish editors would pick up a .foorc in the directory of the > > > edited file. This would pay off much larger. > > > > I wish we had an extensible editor written in Python and Qt. Then > > we'd just be able to configure to our hearts extent! With Qt 3.0's > > new editor widgets and the release of PyQt 3.0 such a beast may not > > be that far away. > > There were also some folks itchin' to write a Pythonic emacs from > scratch to replace the LISPish emacs. Idea was to both improve the > design of emacs and use a better language all at the same time. > > Come on, Ian. You know you want to. ;-) Well, actually, I had fully cloned Emacs functionality in Python just a few weeks ago, and I put it in my pocket here and... oh, damn, it must have fell out in the train. Oh well, there goes that idea. ___ Webware-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-devel
Re: [Webware-devel] Wiki is out of space
On Wed, 2002-01-02 at 15:28, Chuck Esterbrook wrote: > Does anyone know how to get in contact with Ian Bicking, who runs our > Wiki? I fear he won't get this e-mail because of space problems (see > below) and I don't see a phone number on colorstudy.com. My phone is on there somewhere... oh, resume I guess. Anyway, I just got back from vacation, so I wouldn't have mattered. I don't know quite how that happened. 85Mb of error messages from Webware helped, some... man, those really rack up... but I must have some nasty cruft lying around elsewhere too. The things you notice when you run out of space. Anyway, it's back working again. Use terse sentences to conserve space! Ian ___ Webware-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-devel
Re: [Webware-devel] mime type of served documents
UnknownFileTypeServlet.py seems to already do this.
filetype = mimetypes.guess_type(filename)
mimeType = filetype[0]
mimeEncoding = filetype[1]
if mimeType==None:
mimeType = 'text/html' # @@ 2000-01-27 ce: should
this just be text?
response.setHeader('Content-type', mimeType)
If that's not working for you, maybe you need to give the mimetypes
module a hint on your filetypes. You would want to update your
mime.types file.
On Fri, 2002-01-11 at 11:00, Federico Di Gregorio wrote:
> hi,
>
> i didn't found a way to tell webware to set the correct mime type for
> served files (my problem is that css are server as text/html and not as
> text/css). i missed something or should i write the equivalent of
> mod_mime for webware? from were to start in that case? (and no, having a
> separate directory and serving files from there with apache is not an
> option, it is a kludge.)
>
> ciao,
> federico
>
> --
> Federico Di Gregorio
> Debian GNU/Linux Developer & Italian Press Contact[EMAIL PROTECTED]
> INIT.D Developer [EMAIL PROTECTED]
> 99.% still isn't 100% but sometimes suffice. -- Me
___
Webware-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/webware-devel
Re: [Webware-devel] FunFormKit and ›
On Fri, 2002-02-22 at 12:03, [EMAIL PROTECTED] wrote: > I am trying to set the name of a button to > " Begin › " and the & gets converted to & > > Is there a nice way to stop that other then editing the FFK code? Sadly, no. I would recommend you change htmlEncode so it will encode some character into ›, and then use that character in your button text -- I feel like that's the cleanest way. Ian ___ Webware-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-devel
Re: [Webware-devel] Re: Sessions leaking memory?
On Sat, 2002-02-23 at 16:33, Chuck Esterbrook wrote: > I'm using SessionMemoryStore with a time out of 1 on Python 2.1.1 on > Linux with Webware cvs. I cleared out my Sessions/*.ses before > launching the app server. > > The memory grew and after the sessions had expired (according the Admin > servlet), the memory was the same, which smells like a leak, BUT... > > What's also interesting is that when I reran the test program, after > expirations, the memory didn't grow anymore except for a couple blips > (that came back down). Well, as I remember the allocated memory doesn't cause any load on the machine until it is actually used -- once it's actually uesd, I don't know if it can be put back without freeing it. Maybe Python's being smart by not freeing memory that it will probably need later (since an application will usually not shrink in memory except temporarily). Maybe it actually is using resources, but again Python doesn't free memory quickly because there's a good chance it will be needed again -- if that was the case, I'd imagine there'd be some command-line or compile-time option to turn that off. Maybe Python would actually free that memory after some time...? Anyway, the behavior is probably deliberate, and probably a good idea. It may or may not be the same on Windows. I think top should show some distinctions between these different types of memory use. Ian ___ Webware-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-devel
Re: [Webware-devel] What's needed for Webware 1.0? A braindeadinstaller
On Mon, 2002-04-08 at 21:01, Terrel Shumway wrote: > On Tue, 2002-04-02 at 06:55, Geoffrey Talvola wrote: > > Now that 0.7 is out, I think it's high time that we moved Webware in the > > direction of a 1.0 release. What things still need to be done? > > > > Not essential, but nice-to-have: > > (based on my personal experience of picking up a copy of webware after a > very long rest) > > * A wiz-bang GUI installer & launcher: > click, click, click, open browser I don't know this for a fact, but I imagine making a GUI Windows installer is similar to making the equivalent fancy Linux installer (which is an rpm/deb) -- and similarly, distutils is probably the key to doing it Right. ___ Webware-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-devel
Re: [Webware-devel] What's needed for Webware 1.0? A braindeadinstaller
On Tue, 2002-04-09 at 01:11, Terrel Shumway wrote: > On Mon, 2002-04-08 at 19:25, Ian Bicking wrote: > > On Mon, 2002-04-08 at 21:01, Terrel Shumway wrote: > > > * A wiz-bang GUI installer & launcher: > > > click, click, click, open browser > > > > I don't know this for a fact, but I imagine making a GUI Windows > > installer is similar to making the equivalent fancy Linux installer > > (which is an rpm/deb) -- and similarly, distutils is probably the key to > > doing it Right. > > Distutils does half of the job, and is OK for many purposes. My purpose > is to make a *braindead* installer: I'm thinking that the installers use distutils to describe the package, and set up the installer. I haven't used these installers, this is just what I imagine. I know py2exe uses distutils. Just like with rpm/deb, distutils doesn't make it happen -- but it does bring you a whole lot closer. >* no python installation necessary That's hard... you'd have to install Python, but maybe as part of Webware -- something like py2exe doesn't make sense, since you aren't setting up an application, you are setting up a programming environment. I think it would be hard to make this any simpler or more robust than simply telling people to install some version of Python for Windows (of course, outside of Windows none of this installer stuff makes sense). >* no admin rights necessary >* no webserver necessary Doable with an embedded web server... Webware Experimental has one, I think...? (Also distutils) >* easy to setup multiple sites To the degree that setting up contexts could be easier, sure... that could even be done from the Webware admin screens. Virtual sites are more complex, and probably not quite so straight-forward that they are worth putting in the dead-simple installation. Separate AppServers are of interest, easy if the AppServer is a program, hard if it's a service. >* easy to clean up when you are done playing > > > Phase 2 (probably after 1.0) would be a set of management tools for a > real deployment: >* compile and install mod_webkit For Windows it would be precompiled. Installation should only mean copying, I think. >* install mod_rewrite rules? This is doable -- a simple query of where in the path Webware should go, and then set up the simple ... could be put in. >* manage multiple webware "instances" > * start,stop,pause, configure service > * edit configuration > * add/remove/edit contexts/plugins > * load-balancing > * user name/passwords > * backup/restore > * manage log files > * manage error files Most of these could be added to the admin screens, so it would benefit all. Well, user handling isn't standardized so that wouldn't work. >* integration with boa-constructor What's that? I suppose this stuff should go on the Wiki at some point... Ian ___ Webware-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-devel
Re: [Webware-devel] What's needed for Webware 1.0? A braindeadinstaller
On Tue, 2002-04-09 at 20:11, Terrel Shumway wrote: > > Most of these could be added to the admin screens, so it would benefit > > all. Well, user handling isn't standardized so that wouldn't work. > > > I hate browser-based admin screens 8-P (personal preference of course) Heresy! ___ Webware-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-devel
Re: [Webware-devel] What's needed for Webware 1.0? A braindeadinstaller
On Tue, 2002-04-09 at 23:37, Terrel Shumway wrote: > On Tue, 2002-04-09 at 20:51, Tripp Lilley wrote: > > We could take the pains to make a lean, mean Apache package > > What would it take to create a "lean, mean Apache"? > > mod_rewrite > mod_webkit > mod_ssl > mod_auth_db > mod_ssi (or mod_patch) > > cut out everything else? I think it wouldn't even include these -- rather, you'd also include what mods were important to your particular project (i.e., Webware would have mod_webkit, mod_rewrite, and mod_ssl -- mod_auth_db and mod_ssi don't seem important to Webware -- another project might not have mod_rewrite, or might have mod_auth_db, etc). You could cut the build tools and documentation, maybe even mod_fancy_index (that's a mod, isn't it?) and a bunch of other near-standard modules. At the same time, Webware is close enough to a built-in web server that that seems near as simple. Anyway, this should be clearly directed at *only* Windows. These issues are all much better dealt with by the packaging systems on Linux OSes. > For future proofing, use Apache 2.0 now, rather than 1.3 I suppose, but it should also be possible to use 1.3 since you aren't looking for a featureful server anyway, just a compact and reliable one. Anyway, this might not be at all difficult, or maybe it's already been done. The whole module system seems to be meant to facilitate this, and make Apache easy to trim down. Ian ___ Webware-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-devel
Re: [Webware-devel] What's needed for Webware 1.0? A braindeadinstaller
On Wed, 2002-04-10 at 01:40, Tripp Lilley wrote: > > I think it wouldn't even include these -- rather, you'd also include > > what mods were important to your particular project (i.e., Webware would > > have mod_webkit, mod_rewrite, and mod_ssl -- mod_auth_db and mod_ssi > > don't seem important to Webware -- another project might not have > > mod_rewrite, or might have mod_auth_db, etc). > > +1, though I might even drop mod_ssl and mod_rewrite on the floor :) > Those can always be "added" by the user when they decide they need them, > at which point they're theoretically more willing to invest some time in > tweaking the config. mod_rewrite fills in a number of gaps in Webware, so until Webware does better URL handling natively I think it has to be included. mod_ssl is just kind of cool to include, though not necessary. Unlike SSI or somesuch, mod_ssl is orthogonal to webware (like mod_gzip). > > Anyway, this should be clearly directed at *only* Windows. These issues > > are all much better dealt with by the packaging systems on Linux OSes. > > I disagree with this, and I can do so legitimately, as I'm a Linux user > (Mandrake, specifically). In fact, my intention would be to build a > "Webware trivial install" RPM. A savvy Linux user can choose to grab the > RPM (or sources) that will best mesh with everything that's already > installed by the system. On the other hand, someone who may or may not > have already hacked their installed stuff beyond recognition will be able > to grab the "trivial install" RPM and install it so they can get up and > running quickly without screwing up their installed stuff. I use Debian, so maybe I have a different perspective -- I'm used to packages installing easily and interacting very well. So I would envision the Debian Webware package installing easily and working well with the standard Apache package. "apt-get install webware" is as trivial as you can get, after all :) I don't see any reason that couldn't install Webware in a very usable, if generic, manner. Ian ___ Webware-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-devel
[Webware-devel] extraURLPath definitely broken in 0.7
extraURLPath is definitely broken in 0.7. You can reproduce by turning the setting on (of course), and then accessing: /Examples/View/test which should work, as the extra /test should be ignored (and was in past versions). This *does* work: /Examples/View.py/test I looked into this quite a bit, and couldn't figure it out... there's so much cruft in the servlet finding routine that I can't figure out what's supposed to be going on. The routine *was* finding the proper servlet, but ended up forgetting it sometime later. If I was to try to fix it, I would rewrite the entire thing. I was using 0.5something in an application that uses extraURLPath extensively, and I'm trying to move it to 0.7... if it doesn't occur to someone how to fix this, I'll probably go ahead and try to rewrite that code. Ian ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Webware-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-devel
Re: [Webware-devel] extraURLPath definitely broken in 0.7
On Fri, 2002-05-31 at 13:10, Tavis Rudd wrote: > It's based on Steve Purcell's httpsession.py. Unfortunately I've recently > discovered that httpsession.py is based on Python's original urllib rather > than urllib2 so it doesn't work with https requests. That shouldn't be a > problem for testing WebKit though. I've been using httpsession with SSL without a problem... I think httpsession uses httplib, not urllib. Ian ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Webware-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-devel
RE: [Webware-devel] extraURLPath definitely broken in 0.7
On Fri, 2002-05-31 at 12:56, Geoffrey Talvola wrote: > It might be useful to look at the revision history in CVS -- you may be able > to figure out where it broke. But it sounds like this whole area needs a > rewrite anyway. I'm going to try to rewrite this. I'm going to do it for the extra-path case -- I don't really think there's a significant benefit to not having it on, and having two algorithms is confusing and causes more bugs. If people *want* to have it off, there can be an assert that extraURLPath is None (well, give a 404). We can still do caching, it'll just be a bit slower when people are actually using extraURLPath. I'll also get rid of the Main.py problem, but not add any other features. Ian ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Webware-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-devel
[Webware-devel] Object superclass
The Object superclass isn't being used, is it? It seems like an idea that didn't end up being used, and it's somewhat in conflict with the object class in Python 2.2. Ian ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Webware-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-devel
[Webware-devel] Content-type handling in HTTPRequest
The updates Chris gave for accessing non-form-variable data are checked into CVS, adding a fieldStorage() and rawInput() method to HTTPRequest, where rawInput() is equivalent to xmlInput() (which is now gone). (And the FieldStorage problem Chris noted should be fixed -- Chris, you should test it, since I don't have anything that submits POST data like you describe) Ian ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink ___ Webware-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-devel
Re: [Webware-devel] Fixing doc strings
On Thu, 2002-06-20 at 13:40, Edmund Lian wrote:
>
> Ian Bicking wrote:
>
> >I'd like to fix all the '''-quoted doc strings in Webware (replacing
> >them with """).
>
> I must have missed the discussion about this... what's wrong with ''' doc
> strings? I've been using these because it's easier to type than """...
Emacs doesn't quite grock triple-quoted strings. It parses
'''something''' as ('')('something')('') -- this works fine most of the
time, but it means that: '''what's wrong here?''' gets parsed as
('')('what') and then it gets confused and breaks totally (it sees a
line (s wrong here?)('')('...hanging)).
This doesn't happen often with """, since if there's " embedded in the
string, they are usually balanced.
Ian
---
Sponsored by:
ThinkGeek at http://www.ThinkGeek.com/
___
Webware-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/webware-devel
Re: [Webware-devel] Fixing doc strings
On Thu, 2002-06-20 at 14:01, Edmund Lian wrote: > > Ian and Tavis, thanks for the quick reply regarding single versus double > quoted triplets. Seems to me though, that if the issue is Emacs can't > understand triple quoted strings that use apostrophes, then Emacs should be > fixed, not Python source code. That would be nice, but it won't happen anytime soon. I think it would mean significant changes to Emacs (not just the Python mode). It seems like there's something in the Emacs parsing code that presumes one-character tokens (parenthesis, quotes, etc). > Once everybody starts going down the path of adapting coding habits to the > limitations and idiosyncracies of editors, there'll be no end of trouble. > E.g., "oh, editor X doesn't handle Y well, so let's not use Y either, since > we did the same for Emacs". I can't see any particular reason why one > should favor helping Emacs over another editor... Because there are many people using Emacs as their primary IDE, and using """ isn't a big deal. If some other major editor had an issue that was trivial to fix, then that would be fine by me. Of course, there are very few editors that are "major", but so be it. Ian --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Webware-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-devel
Re: [Webware-devel] cvs is broke
I'm confused... I'm not getting the same thing. But then, I'm unclear enough on CVS that I might not be looking at the same version of the file as you. On Fri, 2002-06-21 at 19:50, Chuck Esterbrook wrote: > $ python ExceptionHandler.py > File "ExceptionHandler.py", line 212 > Writes a table whose contents are given by listOfDicts. The > ^ > SyntaxError: invalid syntax > > > This probably came from the ''' --> """ change. What's interesting is > that I expected install.py to crap out since it supposedly bytecode > compiles everything. So maybe it doesn't! > > -Chuck > > > > --- > Sponsored by: > ThinkGeek at http://www.ThinkGeek.com/ > ___ > Webware-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/webware-devel > --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Webware-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-devel
Re: [Webware-devel] mod_webkit multi-AppServer
To experiment with the feature set, as opposed to the actual speed, it might be best to start with WebKit.cgi (or probably just Adapter.py), and then port to mod_webkit. Actually, it might work okay for speed too, since you'd still have balancing -- the front box would just have to be beefier. There was talk of associating users with particular instances of the AppServer, via the SID, so that session data didn't have to be shared. This would be a nice feature, and probably pretty easy to implement in Adapter.py. And, not to abort these ideas at all, there's also that Zope balancer that sounds very interesting -- particularly in taking the SSL load off the AppServer machines while doing balancing at the same time... and then if you added caching to the mix, that would be a very nice balancer. On Mon, 2002-07-01 at 12:37, Terrel Shumway wrote: > On Sun, 2002-06-30 at 12:21, Bobby Kuzma wrote: > > Is there anyone actively working on reworking mod_webkit to support multiple > > AppServer instances, as described in the Wiki. I'd like to try implimenting > > it, but I don't want to step on anyone elses toes in doing so. > > I did a patch to mod_webkit some time ago that would do a very simple > round-robin among multiple servers. It may or may not be useful as a > starting point. I am pretty rusty with C, and this was the very first > apache module I worked on. > > http://jaguar.sourceforge.net/webware/mod_webkit/ > > -- Terrel > > > --- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > ___ > Webware-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/webware-devel --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Webware-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-devel
RE: [Webware-devel] Webware distribution layout/permissions (was Re: Webware (Free)BSD-Port?)
On Thu, 2002-07-11 at 09:51, Geoffrey Talvola wrote: > Stefan Schwarzer wrote: > > On Wed, 10 Jul 2002, Tavis Rudd wrote: > > > how are you assigning permissions on > > > /usr/local/Webware vs. > > > /usr/local/webware. > > > > /usr/local/Webware is simply a copy of the directories and files as > > extracted from the tarball. I didn't change any permissions. The > > owner/group of these files is root:wheel. > > > > /usr/local/webware is generated from the AppWorkDir.py script. Here, I > > also have nothing done on the permissions. However, the user/group of > > the whole /usr/local/webware is webware:webware. > > I'm not following this whole discussion, but I did notice this. PLEASE > don't create two directories that differ only by case... I don't know BSD conventions, but it seems like the local files (/usr/local/webware) should go in /var/lib/webware, /var/www/webware, /home/webware, or somesuch -- /home/webware seems most likely, especially if you create a webware user. Or maybe /usr/local/Webware should go in /usr/local/share/Webware. Ian --- This sf.net email is sponsored by:ThinkGeek PC Mods, Computing goodies, cases & more http://thinkgeek.com/sf ___ Webware-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-devel
Re: [Webware-devel] Python 2.2 compatibility
On Tue, 2002-09-03 at 16:51, Edmund Lian wrote: > Say, are there any plans to have Webware be fully Python 2.2 compatible? > I'm thinking specifically about the issue of Webware's classes not being > new style classes. Without this, it isn't possible to take advantage of the > new multiple inheritance method resolution system, and also the super() > call. It *is* 2.2 compatible (AFAIK), I think you are proposing that it should use 2.2 features. This would make it incompatible with pre-2.2 Python. Tavis I believe played around with some of those 2.2 features in Webware Exp, but it didn't go so well. A number of the features seem like they'd be beneficial when you were designing something, but Webware is already pretty much designed. Super and the new inheritance rules are nice, but they aren't huge. Ian --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 ___ Webware-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-devel
Re: [Webware-devel] Python 2.2 compatibility
On Wed, 2002-09-04 at 02:02, Edmund Lian wrote: > > On 09/04/2002 02:41:19 AM Ian Bicking wrote: > > >It *is* 2.2 compatible (AFAIK), I think you are proposing that it should > >use 2.2 features. This would make it incompatible with pre-2.2 Python. > > Are you sure about this Ian? AFAIK, calls like super() and use of the new > multiple inheritance method resolution algorithm are only possible with new > style classes. Since none of the Webware servlet classes uses 'object' (as > opposed to 'Object', the mother of all Webware objects) as a base class, > then by default none of the servlet classes supports Python 2.2 stuff to > the full extent. For example, when I experimented with this the other day, > I got a "TypeError: super() argument 1 must be type, not class" message > in the traceback. > > The inheritance chain used in Webware for servlets is: NamedValueAccess --> > Object --> Servlet --> HTTPServlet --> Page. Making Webware use object as > the base class so that one can use super() etc. does not appear to be as > simple as having NamedValueAccess subclass object. It makes other parts of > Webware blow up. I think you are still confusing 2.2-compatibility with taking advantage of 2.2 features. Webware is 2.2 compatible, but does not use any 2.2 features. If it did it would *require* 2.2. I'm sure you are correct that Webware would require some changes to the base system to make things like super() work. It seems like it's best to wait until there's some more significant features of new-style classes before Webware gets rid of backward compatibility, though. (Properties would be one such feature, but I don't know if anyone is certain how/where/if they should be used right now). Ian --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 ___ Webware-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-devel
[Webware-devel] New path algorithm is CVS
I finally did the new algorithm for serverSideInfoForRequest (which has been broken for some time). It's checked in, but won't be enabled unless you add 'UseNewPathAlgorithm': 1 to Application.config (since it may break things for people) -- the old algorithm is still there untouched. There's some cruft in dispatchRequest which should be removed if this algorithm becomes the default -- FilesToHide and such -- which may have been the source of the original problem (at the time I was trying to debug the problems with extraURLPath, I didn't even know there was URL munging going on in this dispatchRequest). I don't know what the performance change is, but the new code is much, much shorter. Should be a maintenance gain. I've encountered some weird stuff with the PSP tests -- but I think they are already broken. Anyway, I could use some help debugging this stuff -- forwarding is broken, I think, but I don't know what the proper behavior is. This might be a nice place to start some automatic regression testing, especially since it would have helped before. Has anyone done anything toward this yet? Ian --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Webware-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-devel
Re: [Webware-devel] non-file URL handlers
On Fri, 2002-09-27 at 13:09, Tripp Lilley wrote: > > Now, what I was worried about above, is that if /dav/some/file is > > actually ON the filesystem, it might go there instead of to the > > short-circuited servlet. > > Does either of the ExtraPath methods you described (/dav/index.py or > /dav.py) avoid this? Obviously, since I want the DAV servlet to handle > reads -and- writes to those paths, even if they exist, it's pretty > important that I trap all calls down under /dav/... :) > > (BTW: yes, I'm working on a DAVKit for Webware :) ). Then you should check out DAVKit: http://www.colorstudy.com/software/webware/DAVKit-0.2.tar.gz :) It doesn't deal with erroneous situations that well, and it requires a somewhat new servlet layout (i.e., different than WebKit.Page -- that uses exceptions for more logic). But I've tested it with cadaver and Web Folders, and it basically works. You do need CVS Webware for the extraURLPath fix, and you need to put 'UseNewPathAlgorithm': 1 into Application.config. Ian --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Webware-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-devel
[Webware-devel] Xitame adapter
I was going to put the LRWP adapter into CVS, but a minor question: it includes two files, the adapter and an LRWP library (third party). Where should I put the library? I hesitate to put it in WebKit, because there's already too many files there (it intimidates people, even though WebKit is actually very small). MiscUtils? A subdirectory of WebKit? Ian --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Webware-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-devel
Re: [Webware-devel] Xitame adapter
On Mon, 2002-09-30 at 22:23, Edmund Lian wrote: > On 09/30/2002 11:02:40 PM Ian wrote: > > >I was going to put the LRWP adapter into CVS, but a minor question: it > >includes two files, the adapter and an LRWP library (third party). > >Where should I put the library? I hesitate to put it in WebKit, because > >there's already too many files there (it intimidates people, even though > >WebKit is actually very small). MiscUtils? A subdirectory of WebKit? > > With the increasing number of adapters available, it actually makes more > sense to group all of them under a new directory at the same level as > MiscUtils. It would be nice to move all the adapters off somewhere. The C-based adapters are already separated anyway. I think cleaning up the WebKit directory is worth it, since it's so central. > BTW, has anybody got opinions/comments/adapters for thttpd? I just looked at it, and thttpd looks pretty minimal. I think wkcgi is the only option... unless maybe you wanted to hack mod_webkit-like functionality directly into it and recompile. Seems too hard, but maybe you could modify thttpd's CGI code to do it. Ian --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Webware-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-devel
Re: [Webware-devel] Xitame adapter
On Mon, 2002-09-30 at 22:48, Edmund Lian wrote: > What are the pros and cons of Xitame vs Apache with Webware? I only became > aware of it after your posting about the adapter... Oops, I spelled it wrong -- Xitami. I don't know, I haven't actually used it. Jim Madsen <[EMAIL PROTECTED]> submitted the adapter, and is solely responsible for it, but I figured it should do no harm to toss it in with the rest of them. People were talking about it as an easy-to-install server (especially on Windows), though some people tried it and eventually felt less than pleased (though I can't remember the issues). Ian --- This sf.net email is sponsored by: DEDICATED SERVERS only $89! Linux or FreeBSD, FREE setup, FAST network. Get your own server today at http://www.ServePath.com/indexfm.htm ___ Webware-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-devel
