From: Edmund L. <el...@in...> - 2003-03-30 03:40:25
|
On 03/29/2003 10:25:26 PM webware-devel-admin wrote: > While Chuck's style appeals to me quite a bit, I think the "public >image" of Webware could be spiced up a bit....so I tossed this together: > >http://home.etria.org/webware/ FWIW, I like it... ...Edmund. |
From: Edmund L. <el...@in...> - 2003-03-30 07:19:46
|
On 03/30/2003 01:53:10 AM Ian wrote: >There's a perception -- unfortunately not entirely unfounded -- that Webware isn't >going anywhere. I think we've been making some more progress lately, >and a new website could help people better realize that. I like the >design. Website design aside, that issue of Webware not going anywhere is a thorny one. It is a great, easy to use platform, but we are all reinventing the wheel in that there is no easy way for us to build reuseable, modular applications in the same sense that Zope has (maybe this is a bad example). What I mean is that the very flexible, open nature of Webware that attracted each of us to it also means that each of us uses different bits and pieces to suit our (legitimate) project needs. But building Humpty-Dumpty requires more than finding pieces and trying to fit them together. It actually requires a higher level understanding of what the whole looks like and how current and future pieces can and should fit together. It is this higher level framework that seems to be missing. I, for example, am using Webware, FunFormKit, Cheetah, and PostgreSQL because flexibility and data integrity matters to me. Somebody else might use Webware, PSP, MiddleKit, and MySQL, because ease of development and deployment matters to him. When this happens, we can't use each other's model or controller logic (I'm using the MVC paradigm as a basis of discussion here) because we don't even have a consistent way to reuse basic stuff like user authentication, security, etc. And we can't reuse the view level logic because we don't use the same presentation level techniques. It seems to me that for Webware to go anywhere in terms of developing a rich selection of ready-to-run packages and universally useful things like authentication and security, we need to agree to some standard application-level framework, API, database, etc. ...Edmund. |
From: Edmund L. <el...@in...> - 2003-03-30 16:35:03
|
On 03/30/2003 09:01:28 AM webware-devel-admin wrote: >I think being self-hosting is a big deal, so I'm going to keep going >with it in that direction. This will give us an idea of how well Webware performs underload--assuming we managed to get a lot of active users, or just get /.'d. ...Edmund. |
From: Tom v. S. <tv...@et...> - 2003-03-30 19:46:45
|
On Sun, 2003-03-30 at 11:34, Edmund Lian wrote: > On 03/30/2003 09:01:28 AM webware-devel-admin wrote: >=20 > >I think being self-hosting is a big deal, so I'm going to keep going > >with it in that direction. >=20 > This will give us an idea of how well Webware performs underload--assumin= g > we managed to get a lot of active users, or just get /.'d. Yeah, one thing Webware lacks is some real world examples of stability/robustness/anything. -T |
From: Paul B. <Pau...@em...> - 2003-04-09 11:53:35
|
Edmund Lian wrote: > > Website design aside, that issue of Webware not going anywhere is a > thorny one. It is a great, easy to use platform, but we are all > reinventing the wheel in that there is no easy way for us to build > reuseable, modular applications in the same sense that Zope has (maybe > this is a bad example). I don't think it's that bad an example. Zope is component-oriented, after all. However, I do agree that in certain respects, it can be unclear... * Where to develop certain functionality. The repeated discussions on user handling seem to underline this. * How to reuse other people's contributions. Zope is arguably a lot clearer on this - distribute Zope Products and others may be able to integrate them cleanly into their solutions. > What I mean is that the very flexible, open nature of Webware that > attracted each of us to it also means that each of us uses different > bits and pieces to suit our (legitimate) project needs. But building > Humpty-Dumpty requires more than finding pieces and trying to fit them > together. It actually requires a higher level understanding of what > the whole looks like and how current and future pieces can and should > fit together. It is this higher level framework that seems to be > missing. Yes, Webware puts everything onto the Python level, meaning that application development experience in Python can be used more effectively, and with integration into the Webware framework at the correct level (my favourite point is the servlet factory) you can make Webware fit your own code to a significant extent. However, since there are many different points at which integration can occur (servlet factory, Page subclasses, PSP resources, other things I haven't looked into), there is arguably a dilemma about how and where in the framework code should be developed and deployed to encourage widespread reuse. Moreover, the plug-in mechanism doesn't seem to go far enough in encouraging extensions which work across all these points of deployment, at least as far as I can tell. > I, for example, am using Webware, FunFormKit, Cheetah, and PostgreSQL > because flexibility and data integrity matters to me. > Somebody else might use Webware, PSP, MiddleKit, and MySQL, because > ease of development and deployment matters to him. When this happens, > we can't use each other's model or controller logic (I'm using the MVC > paradigm as a basis of discussion here) because we don't even have a > consistent way to reuse basic stuff like user authentication, > security, etc. And we can't reuse the view level logic because we > don't use the same presentation level techniques. Indeed. If someone introduces authentication/authorisation as a mix-in class, that method may not be appropriate for other application architectures. How would I cleanly employ such a mix-in in an architecture which has its own kinds of servlets, for example? There is a certain argument for pushing certain kinds of functionality as deep as possible into the framework. Of course, database systems can sit behind a layer of abstraction, and this could be a reasonable approach for other pieces of functionality. Potentially, the plug-in concept could be employed to introduce such things in a manner similar to that exhibited by Zope Products, but I think that the Application class (which seems to be where most integration action really takes place) needs more attention to support such ideas. > It seems to me that for Webware to go anywhere in terms of developing > a rich selection of ready-to-run packages and universally useful > things like authentication and security, we need to agree to some > standard application-level framework, API, database, etc. Some things can be done easily. For example, the CGI-style API can be extended to include things like support for content encoding and agent languages. However, other things do not necessarily have easy answers. In effect, Webware gives a degree of architectural freedom that other frameworks might not permit, but defers the addressing of the hard questions that come with that freedom. Paul P.S. I haven't been following the list for over a week, so I hope these issues haven't already been discussed in depth. |
From: Tom v. S. <tv...@et...> - 2003-04-10 15:52:26
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I need to fix my stupid sending rules.... - -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 10 April 2003 02:37 am, Ian Bicking wrote: > On Wed, 2003-04-09 at 18:09, david e wrote: > > http://www.fatslice.com/tmp/webware_www_sketch1.png http://home.etria.org/webware/TODO Complete with very in-complete TODO list. > Looks nice, though it could use higher contrast -- black on gray is > fine, but the other text is too low in contrast. Personally I don't like gray bg's much (reminds me of Yahoo and old no-background-set websites). > I like the layout, with the menu at the top, news to the side, > presumably the "why you'd use Webware" schpeal in the larger section. > > > > At some point we need to decide on a decision process for the site and > logo... My plan is to do 2-3 templates of the website (with diff logo's) and to then call for a vote. My personal favorite is the current setup, but I still want to do a few others as alternatives. Once I have a decent method for 'skinning' the site, I'll toss a note out to the list. I can even give a template so peeps can see what var's go where and can submit their own templates. - - -Tom - - -- Tom von Schwerdtner <tv...@et...> The Etria Group - -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+lVJGThW3Nph/pFMRAoZRAJ0XSjKjrQr08MSfCTql5cJltOuBZgCgj+OI JV+OWRyVAC4fmT7SB0N7/nY= =oDjG - -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+lY4BThW3Nph/pFMRAjWYAJ9POz350jbzbsNdADSrj7EuVn+I2ACeNNiT mCTSRaEWQU38PdRFFnEiEIQ= =7KLh -----END PGP SIGNATURE----- |
From: Paul B. <Pau...@em...> - 2003-04-11 15:05:37
|
Hello, > http://home.etria.org/webware/TODO > > Complete with very in-complete TODO list. One thing that the current site does well, although it could be just my own personal perception, is the organisation of content. I find that the things I want to find most quickly when visiting a software site are: * Concise descriptions of what the software does. Often, I don't find my own expectations met immediately, especially when I just want to know whether the software provides a specific feature or way of doing things. The current Webware site conveniently describes Webware in an immediately visible location. * Links to downloads and documentation. Quite often, these are placed in "navigation bars", and this is what the redesigned site does, but one has to be careful not to design such navigational aids "into the background" in the sense that readers effortlessly ignore or skip over them in their stressed search for the information they need. It has been noted that the Python site, for example, has suffered from its own evolution, and it is now the case that unless you know what Python is, you need to scroll down before you find anything that might immediately qualify as an explanation. On the left hand side, the reader potentially drowns in a sea of possibly meaningless links. I would suggest that the Python site serve as an example of the pitfalls of intuitive site organisation. > Once I have a decent method for 'skinning' the site, I'll toss a note > out to the list. I can even give a template so peeps can see what > var's go where and can submit their own templates. Interestingly, on the subject of site skins, I'm increasingly getting used to Plone-like site layouts, although I do feel that they are somewhat constraining and suboptimal. Anyway, it's interesting to see what you've been up to, and I look forward to future developments. Paul |