 |
New Civilization News: The Annotated Web |
Category: Shared Purpose 30 comments 29 Nov 2003 @ 06:57 by Natalie @82.35.43.4 : your ANTRoger, I love your ant, *and* the idea of the project. When it's set up, I'll join. My only quibble concerns the 'popular/unpopular' rating system since I'm not in favor of that competitive/cliquey/snobbish tendency that can be found in the blogosphere. It has an unfortunate ressemblance to the same thing in the 'real world' outside cyberspace. 29 Nov 2003 @ 08:16 by ming : Browser Parcel That sounds almost inevitable, and sounds like it could be done without the Chandler team. Of course I don't understand the whole thing yet, but if it is really as modular as it looks like, I can't see why not. 29 Nov 2003 @ 08:24 by ming : Mozilla The Mozilla browser has a lot of hooks for creating customized interfaces, and connecting up with most of the inner operations of the browser. Like, see {link:http://www.newsmonster.org/|NewsMonster} which is a fancy RSS aggregator within Mozilla. I don't know much about how that works, but it wouldn't be surprising if you could intercept links and provide panes for entering comments and ratings. Plus it has the Composer component which lets you edit webpages within the browser. 29 Nov 2003 @ 17:10 by Roger Eaton @209.55.71.129 : ratings / popularity Tough quibble to answer, Natalie. I suppose we can call it "interest" instead of "popularity", but it amounts to the same thing and even our {link:http://www.nataliedarbeloff.com/bloggersparliament.html|Bloggers Parliament} vote for best solution has the same idea built in. I would only add an interest rating to the yes/no vote so we don't end up picking {link:http://www.ivillage.co.uk/workcareer/survive/stress/qas/0,9581,156473_162162,00.html|"alternate nostril breathing"} as the Parliament's best solution because it gets the most ayes and the least nays! 29 Nov 2003 @ 21:59 by Natalie @82.35.43.4 : popularity True, but in the case of Bloggers Parliament the term 'best solutions' means those most relevant to the problem, not those that are necessarily most popular. H'm. That leads to another question: who will decide what solutions are most relevant? Maybe there could be some fixed criteria - like "what works" and "what sounds good but hasn't a hope in hell of working". Etc. What do you think? 30 Nov 2003 @ 09:41 by Roger Eaton @209.55.71.129 : re: popularity What might work is to give each voter one thousand credits to spread amongst the solutions. This keeps the parallel to Parliament, where there is no one winning policy, but rather a set of priorities are developed. I advise against equating "best" with "most relevant" -- doesn't meet the crossword puzzle criteria of meaning. 30 Nov 2003 @ 11:42 by Natalie @82.35.43.4 : popularity Not sure I understand, Roger. How would this actually function? Sounds a bit complicated to implement technically. As for relevance, surely that has to be the major criteria for any solution? To give an exaggerated example, if somebody proposes that the best solution to terrorism is to nuke all countries on Dubya's "axis of evil", and if those who actually do think this would be the best solution vote for it in large numbers, are we really going to announce that this is the best of all possible solutions? I don't know about crossword puzzle criteria but no way could I defend such a result. 30 Nov 2003 @ 12:51 by Roger Eaton @209.55.71.129 : Voting on the Web I think you have to allow that the vote will not go the way you want it to. Sure a gang of neo-nazis might decide to mess up the results, but more likely things will work out ok. If we wait until the AnnotatedWeb is working, we can require a login, which will help towards preventing multiple votes, and will discourage people who are not serious. The idea about distributing credits is perhaps too difficult to implement, you are right, though it is an option to keep in mind. Relevance is an important criterion,of course. It is just not the only criterion. "Best" is inevitably somewhat subjective. 30 Nov 2003 @ 13:11 by Roger Eaton @209.55.71.129 : re: ming's comments Ming, I just sent the following to the Chandler design list. Let's see what they say. No one has responded to Tom's query yet. Is his idea far-fetched, or well within the realm of the possible? How would it work? The entire browser would not be stuffed into a Chandler pane, would it? Would a good implementation allow bookmarking? So say embedding a browser in Chandler is not on for the core team at this time. Would it be the kind of Chandler addition that would make it into the standard distribution if done well? Or is it off to the Wiki "jungle" for talk like this? I hope someone will take the time to respond. I am very interested in using Chandler for an ambitious peer to peer project -- see http://blog.voiceofhumanity.net -- recent article about Chandler there. Currently my thinking is to develop the InterMix peer to peer product as middleware. In this scenario, Chandler will function as one possible user interface, with at least an email interface in addition. However, I am also looking at the possibility of using Chandler as a platform for the InterMix product. I would need to have a browser embedded in Chandler for Chandler to work as a platform, tho. > Has there been any talk about a browser parcel (capplet?) > Might it be possible to "just" (easy enough for me to say, I > realize) package Firebird as a parcel? The idea of having > an embedded browser, with which I could save clippings or > entire pages directly into the searchable, massagable, > intertwinglable Chandler repository, fills me with great joy. > This might also be a quick way to show many people the light > about Chandler - lots of browsers out there, and scads of > databases, but the world is crying out for a happy marriage of > the two. 30 Nov 2003 @ 14:07 by ming : Chandler Cool. I hope somebody answers. 1 Dec 2003 @ 05:45 by istvan : Not related?, but maybe useful. {http://www.ceptualinstitute.com/uiu_plus/isss98/house-of-eyes.htm#28} 1 Dec 2003 @ 07:11 by ming : House of Eyes Oh, my good friend Heiner Benking. I'd say that sort of relates. 1 Dec 2003 @ 19:46 by Roger Eaton @204.250.12.246 : House of Eyes Thanks for the Benking {link:http://www.ceptualinstitute.com/uiu_plus/isss98/house-of-eyes.htm#28a|link}. I'll see what I can do with it in my next article. Did you mean to include the fragment at the end of the link pointing to footnote 28, which was referenced in the body for this quote: ".. we should never blur the insight that we need socially stabilized world models to live in, and that we can not do without moral orientation." from S.J.Schmidt? I have not heard of Schmidt before, but I do agree with the ideas of "socially stabilized" and "moral orientation" -- so long as we don't go overboard along those lines. 2 Dec 2003 @ 10:01 by Roger Eaton @209.55.71.129 : We have a reply from Mitch Kapor Mitch Kapor has replied to Tom Mueller's question about embedding a browser. Subject: [Design] Thoughts on a browser parcel Date: Tue, 2 Dec 2003 07:19:51 -0800 From: Mitchell Kapor To: design@osafoundation.org To be able to save clippings or pages to the Chandler repository wouldn't seem to require embedding a browser as much as creating a conduit between the browser and Chandler. In fact, it's reasonable to believe a Mozilla plug-in could be created which would do just this, i.e., populate the repository with items generated by the browser. Embedding a browser, per se, raises all sorts of complex user interface issues which may be unnecessary and avoidable. That said, such a project is something which would need to be undertaken by an external developer, as it's not on spec for Canoga. --------end of quote from Mitch Kapor---------------- So now we know. The answer did cover my questions as well. In particular it is clear that stuffing a whole browser into a Chandler pane is not on, though one could render html in a pane using the Mozilla renderer, called Gecko. The problem with that approach is that one would have to code for the standard Stop, Reload, Home, Bookmarks, History, Print and so forth features, plus the fetching code etc etc. It sounds like a big project and that the result would never be as good as a regular browser. On the other hand, requiring the user to have Mozilla in order to have a connection between Chandler and the web is also something of a drawback. It certainly makes it harder for your gazillions of MSIE users to integrate the web with their email, calendar and contacts. They will have to download and install Mozilla or Firebird. Well it is not a show-stopper for Chandler to go that way, but it does hurt. So where does that leave us? Mitch Kapor has given us a pointer here -- develop a plugin for Mozilla. I wonder -- would a plugin for Mozilla also work for Firebird and Camino? Not for Camino, anyway, I bet, and that is not good for the mac connection. The alternative is to go with the InterMix as middleware concept, which allows any browser. This is simpler. We get something out the door in less time. We don't have to support browser code which might break or get complicated as new browser versions come out. We don't have the problem of supporting Camino, too. It would be ideal though, to end up being THE web browser solution for Chandler as well. As middleware, InterMix should support multiple file systems, so we could begin by using the Chandler Repository. They still have issues, but have basically settled on their repository design, I believe. I need help thinking this through to make sure I haven't made a dumb mistake in the overall structure. As I see it now, in order for InterMix to be middleware and to be THE Chandler web interface both, we will need to implement a new idea, the "personal portal". I have been thinking up to this point of community portals being the entrance to the AntWeb. InterMix would be running on a box that is also a web server, and the link to the portal page would invoke InterMix via cgi. This is how the current InterMix works -- see {link:http://sharingLA.org/cgi-win/lastub.exe?hub=0|sharingLA} for a working InterMix implementation. But for a personal portal to work, InterMix will have to be its own cgi server, or the user will have to install a web server. We could go with the idea of installing a web server separately, I suppose, and plan to eventually bring the relevant cgi-server capability into InterMix. Requiring a separate web server install is ok for technical people, but not ok for the average Chandler user. Somehow I feel I may have missed something important in this analysis. Ming? 2 Dec 2003 @ 11:46 by Roger Eaton @209.55.71.129 : More on the Personal Portal idea There is a python product called {link:http://www.twistedmatrix.com/|Twisted} that might do for an embedded server. Might do. There are comments about cgi not working in Windows from 2003, and disparaging remarks about Win98, plus it is a very big package and we only need a little part of it. Thinking on what I have missed -- even for the community based AntWeb that does not require a Personal Portal, InterMix needs to act as a browser. What I think is that InterMix as browser will be the simplest sort of animal. The idea is for the original link to the community portal to go to InterMix as a cgi request. InterMix will serve the portal page. This much I know how to do. The portal page will have links to other web pages, but each such link will be wrapped as a cgi request back to InterMix. For instance a link to ming . tv would look like this - h t t p : / / intermix.tv/cgi-bin/imix.exe?"ming . tv" -- something like that. We pass the true link as a cgi parameter. Then InterMix will receive the request and it will in turn go out to ming . tv as if it were a browser. The webserver for ming . tv will return just the main html page -- the same that you get when you "view source" on your browser. Please someone correct me if that is wrong. Normally the browser receives this page and then requests all the jpegs and scripts and so forth that are just references and not themselves part of the main html page. So now, InterMix has this main html page so it can redo all the links so they will come back through InterMix. There is a trick here about relative web addressing that we can handle easily and I am not quite sure how we will deal with frames, but it looks like for the most part, the code is simple. InterMix must act as a browser, but not a complicated one. Please correct me, anyone, cause this is a crucial assumption. I will take a look out there about browsers, too, and how they work. 2 Dec 2003 @ 11:56 by Roger Eaton @209.55.71.129 : Here's a reply to Mitch Kapor came in Notice "relatively small amount of work". That is a good sign. We have no decision yet on direction here. Maybe Mitch's suggestion is a good one after all. Any thoughts? I think I am still inclined to go the middleware route, tho. Subject: Re: [Design] Thoughts on a browser parcel Date: Tue, 02 Dec 2003 10:16:18 -0800 From: Heikki Toivonen To: design@osafoundation.org If anyone is interested in creating such an extension for Mozilla, the best place in my opinion would be the http://mozdev.org website that houses dozens of Mozilla extensions and add-ons. I also think this extension would work better than embedding a browser in Chandler - you would get best of both programs with relatively small amount of work. Mitchell Kapor wrote: | To be able to save clippings or pages to the Chandler repository | wouldn't seem to require embedding a browser as much as creating a | conduit between the browser and Chandler. In fact, it's reasonable to | believe a Mozilla plug-in could be created which would do just this, | i.e., populate the repository with items generated by the browser. | Embedding a browser, per se, raises all sorts of complex user interface | issues which may be unnecessary and avoidable. That said, such a | project is something which would need to be undertaken by an external | developer, as it's not on spec for Canoga. | 2 Dec 2003 @ 12:51 by ming : Server technicalities It is not terribly hard to make a basic webserver, which could be embedded in a program people download. Somebody wrote one in 50 lines or so of Rebol as an experiment. Anyway, increasingly it will be part of the operating system that it already has a basic webserver, like on OSX and, I believe XP. So one might actually start counting on that. CGI as such is not much harder, as it basically is just to run some program and feed the output out to whoever's accessing the webserver. Which you in principle can do in one line of code. I suppose the reason they're phasing out CGI is that it is more of a security risk, and it is resource intensive to have to load a whole Perl or Pyhon interpreter every time one runs a little CGI. The better alternative is that an interpreter is built into the webserver, like PHP, ASP or mod_python. A webpage being served from a webserver is indeed the source of the page, but first there's a bunch of headers, giving an HTML response code (e.g. 200 for success), the referer of the page, a statement of what kind of server it comes from, and a few other details. It is in plain ascii and not hard to to duplicate. 2 Dec 2003 @ 13:17 by ming : Browser So the thought of having to make a browser is to make a way of transparently tracking for the user what links he clicks on, right? I.e. somehow filtering all links through a program that tracks where one went. Indeed it is not hard to grab a page and transform all the links to links that pass through some cgi that will track things. But it somewhat hinders the user experience if one has to go to a particular site before one does one's browsing. It would be best if one just does the normal things one does, including being able to cut and paste a link into the browsers URL field. So we're trying to make a way of mostly keeping the user's normal experience, while still tracking links, right? I'm sure in Mozilla one can write a plugin that intercepts all links. But that's just Mozilla. However, that's not any worse than expecting people to use a special browser. Actually it is much better, as a bunch of smart people work hard at making sure Mozilla is up on everything people want from a browser. One thought is to implement the interception of links in a proxy server. A proxy server is a program that receives all the user's requests for webpages anywhere, and then goes and gets them on his behalf and passes them back to him. So, of course, the proxy server could do whatever it needed to do with the data in-between, including replacing URLs. The proxy server could AFAIK run on the user's own machine, or it could be a centralized server for many people. All that is needed for the user to do is to configure his browser to go through a proxy, and all common browsers allow that in their configuration. 2 Dec 2003 @ 21:07 by roger eaton @209.55.71.129 : more from the Chandler Design list The message below from Heikki Toivonen seems right on, except I am not sure that the tradeoff of not being able to handle MSIE is OK. That I assume is what is meant below by "it might not be possible for some closed source browsers". As if MSIE was just another browser rather than the one that 80 or 90 percent of people actually use and are not about to stop using. Ming, it *does* hinder the user experience to have to go to a site to begin browsing. But it also hinders the user experience to have to install Mozilla and give up MSIE. Maybe the answer is after all to grasp the nettle and implement wxMozilla embedded in Chandler. Then the user is not hindered except by the Chandler community not keeping up with Mozilla. However what you (ming) suggest about a proxy server might be just the ticket. I had no idea it was possible to configure a server to go through a proxy. I don't see where to do the configuring in IE. I'll check it out more thoroughly tomorrow. Here's the interesting new article from the Chandler list. Subject: Re: [Design] Thoughts on a browser parcel Date: Tue, 02 Dec 2003 13:13:07 -0800 From: Heikki Toivonen To: design@osafoundation.org kapil thangavelu wrote: | An alternative (better, imo) starting pointing would be wxmozilla I don't think so. wxMozilla is (mostly) about embedding the Mozilla engine inside a control that can be used easily from wxWindows framework and wxPython. Sure, you could easily embed that in Chandler, but there would still be tons of UI work that would need to happen to drive the browser (buttons, URL bar, bookmarks, history, preferences, ...) - in addition to doing the integration piece that collects interesting browsing information and stuffs it into Chandler (and vice versa). What Mitch (and I and several others at OSAF) think is better is to have the browser(s) evolve on their own, and write *just* the integration part. The downside is that you need to write the integration part for every browser that you care about, and it might not be possible for some closed source browsers. (It should be enough to write just one browser integration parcel on Chandler side.) Of course nothing is stopping you from creating a Chandler parcel that does integrate a browser, but that just seems unnecessary work to me, and you would not benefit from the UI work that the browser developers were doing. 3 Dec 2003 @ 11:40 by Roger Eaton @204.250.12.246 : proxy servers Using a proxy server is also problematic: see http://www.lib.washington.edu/help/knownIssues/#proxy and the solution offered often is to use Mozilla! Here is another link, http://www.library.northwestern.edu/help/proxy/ that tells us "Please note that you may not be able to configure access the Library's proxy server if your computer is on a corporate network that uses its own proxy server to restrict Internet access. Check with your network's system administrator for more information." So corporate users may be restricted with the proxy solution. Also, the two articles about accessing University libraries through proxies from outside the University suggests that those who use proxies now will have to switch proxies back and forth if that is the solution we adopt. Another drawback, even though we might not be talking about a lot of people. Safari for mac os X does not support proxy servers. Proxy server is not available through AOL I.E. The proxy will need to support https -- this means coding the proxy will not be so simple after all. 3 Dec 2003 @ 18:06 by Roger Eaton @204.250.12.246 : Chandler/Browser Quandry I think I see a way to implement the personal portal idea so it integrates any browser to Chandler. First, though, here is a list of the possibilities: 1) The OSAF solution -- set up a pipe between Mozilla and Chandler. An open question here is whether the pipe can work both ways. What we need is for Mozilla to notify Chandler so the user can be tracked, but also we want a way to add Chandler/InterMix options to the Mozilla browser experience. For instance, the user will need to be able to save a reference to a particular web page in a particular category. InterMix will need the user to be able to rate the web page and to add notes and keywords. To implement these needs, Mozilla will have to have a special Chandler tool bar. I think we can assume this is doable. The big drawback is that each browser will need its own code/toolbar. And, it is not totally clear that MSIE can be handled at all, tho the fact that Google has a toolbar on MSIE suggests that it can. (Google says, tho, that the toolbar has conflicts with some other plugins -- {link:http://www.stltoday.com/stltoday/business/stories.nsf/Business/BEE648332E918CA886256DEF00137979?OpenDocument&Headline=A+special+cable+can+make+a+homemade+DOS+printer+program+work|check this article}. Would a Chandler toolbar conflict with the google toolbar on MSIE? You have to wonder. 2) Install Mozilla via wxMozilla into Chandler. In a way, this is the cleanest solution, but it will take a lot of work and the Chandler implementation is likely to be playing catch up to the real thing indefinitely. 3) A proxy web-server embedded in Chandler could be specified in each browser. But this also has problems -- some browsers do not have proxy settings; some people are using the proxy for normal business; the proxy server will have to handle https. To capture ratings, keywords and notes, the embedded proxy server will have to modify the web pages served to add a Chandler Header and Footer with forms with text boxes and radio buttons that can accept ratings and so forth. 4) Implement a personal portal as a button on Chandler. This works something like the proxy solution but requires no setting on the browser. Pressing the browser button in Chandler brings up the default browser on the user's portal page. There is an embedded web server in Chandler, same as for the proxy solution, but the embedded web server is invoked by the browser purely through the href links in the portal page, instead of via the proxy setting in the browser. The href links go to the embedded server with the true web destination as a cgi parameter, so the embedded server works just like a proxy server, but only for the manipulated links. Https links can be left alone -- so the user will not be tracked when using https, but that is as much a feature as a fault. Also, the user will immediately leave the Chandler purview if the browser address window is used. Still the benefits are that all browsers work and the user does not need to do any set up work. This solution gets around the problem that the Chandler user has to go to a portal page, because the invocation of the browser will take the user to the page as needed. (I am assuming it is possible to invoke any browser with a parameter for the initial page to override the user's "home" page. I wonder if that is a good assumption!) Let's discuss and then I'll write it up as a new article if it still looks good. Ming, do you have internet telephone? I am sure you do. I don't care for chat much, but I'd like to talk without spending a transatlantic nickel. I will set myself up on whatever system you are using so we can talk. 4 Dec 2003 @ 09:14 by Roger Eaton @209.55.71.129 : Tom Mueller responds to Mitch Kapor Subject: [Design] Thoughts on a browser parcel Date: Thu, 4 Dec 2003 09:19:21 +0100 From: "Tom Mueller" To: Agreed that an embedded browser isn't (at least today) a crucial PIM feature, that it would ideally be done by an external developer (I can see OSAF staffers glancing nervously at their calendars and getting Inspector-Dreyfus-style tics), and that an external browser plug-in could be made to send clips to the Chandler repository (as notes, a new item type "clips" to facilitate searching, whathaveyou). Just getting the data into Chandler would make it accessible to searches, and allow a host of agents set to work on it, hammer and tongs. Having said this, the same advantages that accrue to having email internal, as opposed to imported into Chandler from Eudora, would seem to exist here as well. Imagine being able to highlight text in an on-board browser, Alt+N to create a new note from it, assign that note on the fly to relevant categories, projects, clusters; then hit Alt+Ctrl+E to clone that note and send as an email to a colleague; then select a few key words of note text and Alt+P to make a new project with those as title words; etc. ad nauseum. All in real time. Hard to see how this would be possible if the browser were external. Also, an internal browser would presumably bring Favorites into the heart of a person's computer experience, instead of the paradoxical periphery they currently inhabit. Favorites could be another item type, to be annotated, assigned hither and yon, shared, etc. The alternative, importing web clippings from an outside program, would risk producing precisely the kinds of intimidating middens of undigested, to-be-reviewed information that Chandler ought to be so good at avoiding. An on-board browser would give Chandler a pretty comprehensive coverage of the internet - web, email, RSS, instant messaging. For the higher education crowd, with the web becoming an indispensable research tool, this would be a compelling capability. All that's needed (from this user's point of view, anyway) is an integrated news reader, and the picture is complete. The UI questions would admittedly be thorny. Balancing the utility of maintaining the identical look and functionality of the outside program (thus facilitating software updates), with the undeniable appeal of giving all Chandler parcels an homogeneous appearance. I'd vote for functionality over homogeneity, whichpresumably would also make the programming significantly easier (and please the folks who initially developed the browser - maybe even getting them to lend a hand?). One of the great beauties of parcel mix-and-matchability is that it allows a few deviations from the Chandler "look." > Message: 4 > Date: Tue, 2 Dec 2003 07:19:51 -0800 > From: Mitchell Kapor > Subject: [Design] Thoughts on a browser parcel > To: design@osafoundation.org > Message-ID: > Content-Type: text/plain; charset=US-ASCII; format=flowed > > To be able to save clippings or pages to the Chandler repository > wouldn't seem to require embedding a browser as much as creating a > conduit between the browser and Chandler. In fact, it's > reasonable to > believe a Mozilla plug-in could be created which would do just this, > i.e., populate the repository with items generated by the browser. > Embedding a browser, per se, raises all sorts of complex user > interface > issues which may be unnecessary and avoidable. That said, such a > project is something which would need to be undertaken by an external > developer, as it's not on spec for Canoga. > 4 Dec 2003 @ 09:31 by Roger Eaton @209.55.71.129 : another post from [Design] Subject: Re: [Design] Thoughts on a browser parcel Date: Thu, 4 Dec 2003 14:11:00 +0200 From: Philip Trauring To: design@osafoundation.org Isn't an embedded browser of some kind required for reading HTML e-mails? I don't think I need Chandler to be my web browser, although if it was and was fully integrated that could be a good thing, but I do need Chandler to be able to support HTML rendering - or am I off-base here? On OS X it would seem logical to use the KHTML-derived WebCore rendering engine (the engine used by Safari, and now OmniWeb). Clearly KHTML is supported on Linux - although I don't know about Windows. The wxmozilla project mentioned in an earlier posting would also seem a good cross-platform option - although might the mozilla code base be too big? I'm not suggesting that supporting HTML rendering is the same thing as offering a full-blown browser with all the features we would expect (bookmarks, history, auto-complete, blocking pop-ups, downloading files, etc...) but it would seem we do need to integrate some browsing functionality. Philip Trauring 4 Dec 2003 @ 20:08 by Roger Eaton @209.55.71.129 : Three more posts from Chandler [Design] The main point here, I think, is the insistence of Heikki Toivonen on sticking with Mitch Kapor's original message that the UI was a show-stopper for embedding a browser as far as he was concerned. Post #1 Subject: Re: [Design] Thoughts on a browser parcel Date: Thu, 4 Dec 2003 13:26:20 -0800 (PST) From: David Neeley To: Philip Trauring , design@osafoundation.org Perhaps I'm off base here, but there should be no reason Chandler can't work with whatever your default browser might be for rendering HTML mail. However, the rendering component in Mozilla--the "Gecko" code--is actually quite small and very fast, unless it's become much more bloated since the last I heard. In my opinion, if we were to want an integrated browser parcel, the Mozilla code makes the most sense of all since it is already cross-platform. David --------------------------------- Post #2 Subject: Re: [Design] Thoughts on a browser parcel Date: Fri, 5 Dec 2003 00:41:32 +0200 From: Philip Trauring To: design@osafoundation.org I for one definitely do not want to have to load my e-mails in a separate browser when they contain HTML. I'd like the option of not rendering the HTML for security reasons, but if I trust the sender I definitely want to be able to view the e-mail as intended without opening another application. That is the approach of Mailsmith, which of course makes sense considering it comes from the creators of BBedit, but that's the exact reason I don't use Mailsmith... Philip On Dec 4, 2003, at 11:26 PM, David Neeley wrote: > Perhaps I'm off base here, but there should be no reason Chandler > can't work with whatever your default browser might be for rendering > HTML mail. > > However, the rendering component in Mozilla--the "Gecko" code--is > actually quite small and very fast, unless it's become much more > bloated since the last I heard. > > In my opinion, if we were to want an integrated browser parcel, the > Mozilla code makes the most sense of all since it is already > cross-platform. > > David --------------------- Post #3 Subject: Re: [Design] Thoughts on a browser parcel Date: Thu, 04 Dec 2003 15:00:19 -0800 From: Heikki Toivonen To: design@osafoundation.org Of course. I don't think anyone wants this. However, embedding an HTML viewer for email (Mozilla for examples) is a separate thing from having a *web browser* in Chandler. An integrated HTML mail view uses a small subset of full browser features and components, and the UI requirements are minimal compared to full featured browser. Philip Trauring wrote: | I for one definitely do not want to have to load my e-mails in a | separate browser when they contain HTML. I'd like the option of not - -- ~ Heikki Toivonen 5 Dec 2003 @ 13:09 by Roger Eaton @209.55.71.130 : resolution of Chandler/Browser issue Best option is the Personal Portal idea. If Mitch Kapor and the other heavyweights at OSAF have discussed and discarded the embedded browser option in favor of the Mozilla toolbar idea (which is not a good solution itself), then despite its appeal, we need to discard the embedded browser solution, too. The Mozilla toolbar option seems very poor because it requires either the users to adopt Mozilla and install the toolbar, or for Chandler to support any number of browsers, including MS IE, and that seems very problematical considering MS anti open-source stance. The Proxy solution shares the problems of the Personal Portal solution and then has some other problems in addition -- we would have to support https in our miminal embedded server, and users who need a proxy for other reasons would not be able to play. So we are left with the Personal Portal idea. This solution requires Chandler to be able to invoke the user's browser of choice with the Personal Portal page as target. If Chandler cannot do this for some reason, then we will have to reconsider. I'll do some research on this issue and if it looks ok, will write up the resolution in an article. 5 Dec 2003 @ 16:42 by ming : Personal Portal Ok, so with 'personal portal' you mean essentially a program running on the user's computer, which will be a URL that tracks everything that is passed through it, and somehow provides a way of rating and categorizing links. And the information would be passed on to Chandler. Right? And there would be a specialized data type added to Chandler, which stores those links/categorizations/ratings. And when one clicks on a link, it goes to the normal browser, but passed through the personal portal page. I doubt that that should be a problem. But, hm, one of the core things that Chandler is about is to have a lot of facilities for categorizing items in many different ways. And most of what you have in mind doing with links to webpages boils down to categorizing them in various ways. So, I'm suddenly worrying whether you'd use Chandler's inherent ability to do that, or you'll do it elsewhere (in the personal portal) and then import the data into Chandler. Where Chandler might be the better place to do it in the first place, as I'm sure that will be what it will be very ingenious at. This is all not quite clear to me. And if Chandler turned out to be perfect for doing the kind of categorization and rating you're looking for, then the question would become how that gets coordinated with loads of other people. I mean, Chandler obviously intends to let people share their data, but doesn't seem to attempt at solving how categories are synchronized between many different members of a certain group, and therefore how the data could be aggregated in the kinds of ways you're looking for. Seems it would important to study how Chandler plans on sharing categories, and whether there indeed might be a way to coordinate categories and rating schemes between many people. But, of course, then there's still the issue that there's no browser in Chandler. But I suppose that won't have to be a problem if a link opens up a page in a browser. 5 Dec 2003 @ 20:09 by Roger Eaton @209.55.71.129 : reply to ming re: Personal Portal > Ok, so with 'personal portal' you mean essentially a program running > on the user's computer, which will be a URL that tracks everything that > is passed through it, and somehow provides a way of rating and > categorizing links. And the information would be passed on to Chandler. > Right? That and eventually a lot more. Once the user passes through the portal, she is in the Annotated Web. Categorized and rated links can be shared via the peer to peer voice of humanity network. > And there would be a specialized data type added to Chandler, > which stores those links/categorizations/ratings. And when one > clicks on a link, it goes to the normal browser, but passed > through the personal portal page. I doubt that that should be a > problem. Yes, I think it will work. > But, hm, one of the core things that Chandler is about is to > have a lot of facilities for categorizing items in many different > ways. And most of what you have in mind doing with links to webpages > boils down to categorizing them in various ways. So, I'm suddenly > worrying whether you'd use Chandler's inherent ability to do that, or > you'll do it elsewhere (in the personal portal) and then import the > data into Chandler. Where Chandler might be the better place to do it > in the first place, as I'm sure that will be what it will be very > ingenious at. This is all not quite clear to me. We will definitely want to hook into the Chandler categories. Our portal page code will be inside Chandler, so we will have complete access to everything. I am not clear on exactly how the categories will work either, and I've poked around quite a bit. Still, maybe I have just missed the relevant pages. In any case, clearly Chandler will have categories and clearly we want to be in sync with them. 7 Dec 2003 @ 16:02 by Roger Eaton @209.55.71.129 : another [Design] post - has some ideas Subject: Re: [Design] Thoughts on a browser parcel Date: Sun, 7 Dec 2003 14:14:03 -0500 From: Selva To: Mitchell Kapor , Hi Mitch, Comments in line: > > From: Mitchell Kapor > Date: Tue, 2 Dec 2003 07:19:51 -0800 > To: design@osafoundation.org > Subject: [Design] Thoughts on a browser parcel > > To be able to save clippings or pages to the Chandler repository > wouldn't seem to require embedding a browser as much as creating a > conduit between the browser and Chandler. There may be some powerful advantages in allowing the repository for saving web clippings be a Chandler edition of OpenOffices Writer application. This of course would mean that Writer would need to be embedded with a HTML viewing module itself. But doing so may allow Chandler to become more useful to the end user as described below. For example, Chandlers version of Mozilla browser could have a button on its toolbar that allows for saving the HTML version of the displayed web page as a Writer document. Of course Writer, at this time, does not have powerful HTML editing features so the web pages saved in this manner would be read only files. However, employment of a HTML viewing edition of Writer as Chandlers web clipping repository allows us to add a second button to the Chandler embedded browsers toolbar that allows for saving just the text of a displayed web page as a Writer document. This of course allows the user be able to edit the text of the web page just as any other Writer document. Due to the multi-frame nature of many web pages with embedded advertisements, it would also be useful if the user could highlight just the portion of the text of a web page that he wants to save and then select from the right click contextual menu, the option to save that segment of text as a Writer document. Furthermore, if the user decides to save a web page as HTML or as text into Writer, then as soon as the first Save action occurs, Chandler could convert the standard browser interface into one with two tabbed windows. The first tab would be for the embedded browser itself, and the second tab would be for the Writer clipboard which displays either the HTML page or the text of the last clipping. This way, the user could always shuttle between the browser and the Writer web clipping repository easily and also access the last clipping for editing and emailing. Once text from a web page is saved in Writer, it might also be useful if an icon could be placed in the left hand margin of the Writer document next to the pasted text. Clicking on the icon could then launch the Chandler browser if its not open already and then take the user to the URL from which that particular web text clipping was taken from. Emailing the clippings either as Writer text document attachment or as a HTML attachment or as PDF attachment might accessed by the user in two ways. 1) This could be done by going to the Writer menu bar and selecting File -> email document in Writer format, or File-> email document as HTML attachment, or File-> email document as PDF attachment. Selecting any of these options would of course launch Chandlers email composition window with the selected Writer file already attached. 2) This could be also accessed from Chandlers email application window using usual Attach File button in the email composition window. Rgds, Selva 11 Mar 2004 @ 20:00 by Casey @129.78.64.100 : web annotation Roger, Thanks for the link to your article, it's good to see that some of these issues are being discussed! I've also been alerted to Gibeo, which has reinvented the web-annotation-wheel. Its implementation relies on proxying and in-page modification, which I feel is flawed. Proxying is flawed because it does not scale (in terms of bandwidth or computation) and in-page modification is less flawed than it is contentious. I think that using a sidebar gives annotations the credibility and weight that they deserve. If they are highlights/breakouts, then they're just parasites upon the original text. A separate presentation encourages serious posts, and also gives more flexibility to the method of presentation. Regarding "automated cross posting or simple aggregation", these are two options for showing annotations as part of a personal blog. The first, automated cross posting, would just produce a blog entry for each annotation entry. This duplicates content but allows it to be managed separately, if that's what you want. The second, aggregation, is what Alan expanded upon: Using the existing mechanisms for blog aggregation (XML/RDF), the annotation server can provide individual annotations to be redisplayed independently of their host page. I'm going to crosspost this comment to your blog just to make my idea more concrete :-) It definitely seems like web annotation is on the rise! 8 Jun 2009 @ 05:57 by jewelry @218.19.53.159 : pearl Read to exercise the brain. Surround yourself with friends. Other entries in Shared Purpose 4 Jun 2010 @ 03:30: Hanging Out. 24 Dec 2008 @ 23:52: Christmas Greetings 29 May 2008 @ 14:56: Cosmic Glue Part 3 20 Mar 2008 @ 10:13: Barack Obama: Rock Church, Rock 20 Oct 2007 @ 19:44: ANOTHER KIND OF EPIDEMIC... as dangerous as any! 21 Jul 2006 @ 01:52: All that Glitters is not of Gold 2 Jun 2006 @ 13:25: Another two NCN'ers meet ! 30 May 2006 @ 15:47: Something is waiting to be known - 17 Apr 2006 @ 13:03: Time Travelor John Titor 25 Feb 2006 @ 14:14: GENETICALLY ENGINEERED FOOD
|
28 Nov 2003 @ 14:44, by Roger Eaton