From renggli at student.unibe.ch Sun Feb 2 19:44:36 2003 From: renggli at student.unibe.ch (Lukas Renggli) Date: Sun, 2 Feb 2003 19:44:36 +0100 Subject: What I did the last week Message-ID: <60E9E1A3-36DE-11D7-9F43-000393CFE6C8@student.unibe.ch> Hi Smalltalkers, As you already know I won't come to the meeting the coming week. Therefore I thought it would be good to give you a brief list of the things I did this week: - First, I went a bit deeper into SIXX to archive xml persistence of the data. It was a bit tricky, because SIXX does a deep-save by default and we would have all data in one single xml-file. Therefore I added code to create a directory structure in the filesystem and to put each structure-item into a single file. Currently there is no loading implemented and the code is not attached to the web-interface, but you can see a small example in StoreTests>>testSave. - Then I started a complete refactoring of the inheritance in the action classes, because we currently had some ugly code-duplications. Most of the problems are solved now but not all the code of the view-actions have been pushed-up yet. - At the same time I improved the versioning and history mechanism. You have now the possibility to restore or to revert to an old version and to truncate history information from any point. I did not write tests for this new features, but more is expected to come. Also I did not add code to handle these things for whole wiki trees, because I think that will be the task for a special management plugin. - I refactored the visitor-classes, because there was a lot of unnecessary baggage and I had to deal with inheritance. Especially the stuff with inheritance (e.g. when #acceptPage: is called also #acceptStructure: has to be called because Page inherits from Structure), but I think I found a good solution. - Today I tested everything on my new mac ;-) , because I couldn't leave that machine any longer without touching but learning exams next to. Cheers Lukas -- Lukas Renggli http://renggli.freezope.org From ducasse at iam.unibe.ch Sun Feb 2 20:21:53 2003 From: ducasse at iam.unibe.ch (Stephane Ducasse) Date: Sun, 02 Feb 2003 20:21:53 +0100 Subject: What I did the last week In-Reply-To: <60E9E1A3-36DE-11D7-9F43-000393CFE6C8@student.unibe.ch> Message-ID: <961AAF30-36E3-11D7-A5D3-000393B2AA24@iam.unibe.ch> > Hi Smalltalkers, Yes we are here. > > As you already know I won't come to the meeting the coming week. > Therefore I thought it would be good to give you a brief list of the > things I did this week: > > - First, I went a bit deeper into SIXX to archive xml persistence of > the data. It was a bit tricky, because SIXX does a deep-save by > default and we would have all data in one single xml-file. Therefore I > added code to create a directory structure in the filesystem and to > put each structure-item into a single file. Currently there is no > loading implemented and the code is not attached to the web-interface, > but you can see a small example in StoreTests>>testSave. does it means that we have one dir for a wiki and for each page? > - Then I started a complete refactoring of the inheritance in the > action classes, because we currently had some ugly code-duplications. > Most of the problems are solved now but not all the code of the > view-actions have been pushed-up yet. > > - At the same time I improved the versioning and history mechanism. > You have now the possibility to restore or to revert to an old version > and to truncate history information from any point. I did not write > tests for this new features, but more is expected to come. Also I did > not add code to handle these things for whole wiki trees, because I > think that will be the task for a special management plugin. Exact. Yesterday I was thinking that a features I would like is to have wiki that redirect to other ones to ease migration and also the possibility to rename wiki. > > - I refactored the visitor-classes, because there was a lot of > unnecessary baggage and I had to deal with inheritance. Especially the > stuff with inheritance (e.g. when #acceptPage: is called also > #acceptStructure: has to be called because Page inherits from > Structure), but I think I found a good solution. > > - Today I tested everything on my new mac ;-) , because I couldn't > leave that machine any longer without touching but learning exams next > to. Which new mac? Pay attention on mac you should get the right VM for VW because it is really slow. If you need software for mac just ask. I started to accumulated a lot of useful goodies and roel has all kinds of professional editions :). > Cheers > Lukas > > -- > Lukas Renggli > http://renggli.freezope.org > > Prof. Dr. St?phane DUCASSE (ducasse at iam.unibe.ch) http://www.iam.unibe.ch/~ducasse/ "if you knew today was your last day on earth, what would you do different? ... especially if, by doing something different, today might not be your last day on earth" Calvin&Hobbes From renggli at student.unibe.ch Sun Feb 2 21:20:35 2003 From: renggli at student.unibe.ch (Lukas Renggli) Date: Sun, 2 Feb 2003 21:20:35 +0100 Subject: What I did the last week In-Reply-To: <961AAF30-36E3-11D7-A5D3-000393B2AA24@iam.unibe.ch> Message-ID: > does it means that we have one dir for a wiki and for each page? No, only chapters (or more general, structure-items that have children) have a directory in the file-system. The rest are just xml-files. I tried to make the basic interface as extensible as possible, so it shouldn't be a problem to create another subclass of Storage to load and save to a relational database, directly to SWiki, etc. > Yesterday I was thinking that a features I would like is to have > wiki that redirect to other ones to ease migration and also the > possibility to rename > wiki. Something like that can be done easily. I've got already something similar to redirect unauthorised users to a login form, but it is not yet accessibly from the web :-( > Which new mac? The latest 15" PowerBook. I ordered already in December and received just yesterday. Unfortunately there is not much time to play with it now ... > Pay attention on mac you should get the right VM for VW because it is > really slow. Yep, I already learned that: First I could not run it, because the installer is OS 9 only; the same is for the VW. Luckily there is one for OS X available to download from Cincom that works quite well. Bug report for Roel: The StarBrowser has has some update-problems with the class definitions when selecting a new class. -- Lukas Renggli http://renggli.freezope.org From ducasse at iam.unibe.ch Sun Feb 9 08:24:29 2003 From: ducasse at iam.unibe.ch (Stephane Ducasse) Date: Sun, 09 Feb 2003 08:24:29 +0100 Subject: Stressing SmallWiki design on integration Message-ID: <87093714-3BFF-11D7-9B64-000393B2AA24@iam.unibe.ch> Hi all, I think that tuesday we should look at a simple problem of integration and see how the extended actions works or not. I was thinking that we will need a kind of configuration object that represents which kind of extension are required. Stef Prof. Dr. St?phane DUCASSE (ducasse at iam.unibe.ch) http://www.iam.unibe.ch/~ducasse/ "if you knew today was your last day on earth, what would you do different? ... especially if, by doing something different, today might not be your last day on earth" Calvin&Hobbes From ducasse at iam.unibe.ch Tue Feb 11 22:33:23 2003 From: ducasse at iam.unibe.ch (Stephane Ducasse) Date: Tue, 11 Feb 2003 22:33:23 +0100 Subject: Tagging page could be a really cool extension. Message-ID: <726D575B-3E08-11D7-B832-000393B2AA24@iam.unibe.ch> Prof. Dr. St?phane DUCASSE (ducasse at iam.unibe.ch) http://www.iam.unibe.ch/~ducasse/ "if you knew today was your last day on earth, what would you do different? ... especially if, by doing something different, today might not be your last day on earth" Calvin&Hobbes From renggli at student.unibe.ch Tue Feb 11 22:42:43 2003 From: renggli at student.unibe.ch (Lukas Renggli) Date: Tue, 11 Feb 2003 22:42:43 +0100 Subject: Tagging page could be a really cool extension. In-Reply-To: <726D575B-3E08-11D7-B832-000393B2AA24@iam.unibe.ch> Message-ID: What do you mean by tagging? Do you think of custom properties assigned to a structure-item? -- Lukas Renggli http://renggli.freezope.org From renggli at student.unibe.ch Tue Feb 11 22:42:43 2003 From: renggli at student.unibe.ch (Lukas Renggli) Date: Tue, 11 Feb 2003 22:42:43 +0100 Subject: Tagging page could be a really cool extension. In-Reply-To: <726D575B-3E08-11D7-B832-000393B2AA24@iam.unibe.ch> Message-ID: What do you mean by tagging? Do you think of custom properties assigned to a structure-item? -- Lukas Renggli http://renggli.freezope.org From ducasse at iam.unibe.ch Wed Feb 12 10:28:11 2003 From: ducasse at iam.unibe.ch (Stephane Ducasse) Date: Wed, 12 Feb 2003 10:28:11 +0100 Subject: Tagging page could be a really cool extension. In-Reply-To: Message-ID: <4DA7E8F7-3E6C-11D7-88F8-000393B2AA24@iam.unibe.ch> A kind of information so that after I can ask show all the pages that do have this tag or not Stef On Tuesday, February 11, 2003, at 10:42 PM, Lukas Renggli wrote: > What do you mean by tagging? > > Do you think of custom properties assigned to a structure-item? > > -- > Lukas Renggli > http://renggli.freezope.org > > Prof. Dr. St?phane DUCASSE (ducasse at iam.unibe.ch) http://www.iam.unibe.ch/~ducasse/ "if you knew today was your last day on earth, what would you do different? ... especially if, by doing something different, today might not be your last day on earth" Calvin&Hobbes From renggli at student.unibe.ch Wed Feb 12 12:49:38 2003 From: renggli at student.unibe.ch (Lukas Renggli) Date: Wed, 12 Feb 2003 12:49:38 +0100 Subject: Tagging page could be a really cool extension. In-Reply-To: <4DA7E8F7-3E6C-11D7-88F8-000393B2AA24@iam.unibe.ch> Message-ID: <10661B1E-3E80-11D7-8760-000393CFE6C8@student.unibe.ch> > A kind of information so that after I can ask show all the pages that > do have this tag or not Unfortunately I forgot to tell about the generic property-management yesterday, that I am currently experimenting with. I already critizized the fact that there was dublicated code with the inheritance over the wiki structure of templates and other similar properties. What I suggested once is to use #perform, but as we discussed in our weekly meeting this cannot be a good solution. What I did now is to use a collection to hold custom tags and to centralize the inheritance of the wiki structure. This seems to me a much cleaner solution and allows to user to add custom data or tags to any component of SmallWiki. For a basic preview of this functionality, you could have a look at some of the test cases I have already written in the class PropertyTests. Cheers Lukas -- Lukas Renggli http://renggli.freezope.org From renggli at student.unibe.ch Wed Feb 12 12:49:38 2003 From: renggli at student.unibe.ch (Lukas Renggli) Date: Wed, 12 Feb 2003 12:49:38 +0100 Subject: Tagging page could be a really cool extension. In-Reply-To: <4DA7E8F7-3E6C-11D7-88F8-000393B2AA24@iam.unibe.ch> Message-ID: <10661B1E-3E80-11D7-8760-000393CFE6C8@student.unibe.ch> > A kind of information so that after I can ask show all the pages that > do have this tag or not Unfortunately I forgot to tell about the generic property-management yesterday, that I am currently experimenting with. I already critizized the fact that there was dublicated code with the inheritance over the wiki structure of templates and other similar properties. What I suggested once is to use #perform, but as we discussed in our weekly meeting this cannot be a good solution. What I did now is to use a collection to hold custom tags and to centralize the inheritance of the wiki structure. This seems to me a much cleaner solution and allows to user to add custom data or tags to any component of SmallWiki. For a basic preview of this functionality, you could have a look at some of the test cases I have already written in the class PropertyTests. Cheers Lukas -- Lukas Renggli http://renggli.freezope.org From ducasse at iam.unibe.ch Thu Feb 13 09:50:08 2003 From: ducasse at iam.unibe.ch (Stephane Ducasse) Date: Thu, 13 Feb 2003 09:50:08 +0100 Subject: Idea : automatic information in templates Message-ID: <276BED4C-3F30-11D7-ACB9-000393B2AA24@iam.unibe.ch> Hi What I would like to be able to say is for a given page that it get automatically time-stamped with the lats update. Stef Prof. Dr. St?phane DUCASSE (ducasse at iam.unibe.ch) http://www.iam.unibe.ch/~ducasse/ "if you knew today was your last day on earth, what would you do different? ... especially if, by doing something different, today might not be your last day on earth" Calvin&Hobbes From roel.wuyts at iam.unibe.ch Thu Feb 13 10:10:20 2003 From: roel.wuyts at iam.unibe.ch (Roel Wuyts) Date: Thu, 13 Feb 2003 10:10:20 +0100 Subject: Idea : automatic information in templates In-Reply-To: <276BED4C-3F30-11D7-ACB9-000393B2AA24@iam.unibe.ch> Message-ID: And with the username, once we get users. I normally don't care about the IP address of who changed the page :-) On Thursday, February 13, 2003, at 09:50 AM, Stephane Ducasse wrote: > Hi > > What I would like to be able to say is for a given page that it get > automatically time-stamped with the lats update. > > > Stef > > > Prof. Dr. St?phane DUCASSE (ducasse at iam.unibe.ch) > http://www.iam.unibe.ch/~ducasse/ > "if you knew today was your last day on earth, what would you do > different? ... especially if, by doing something different, today > might not be your last day on earth" Calvin&Hobbes > > Roel Wuyts Software Composition Group roel.wuyts at iam.unibe.ch University of Bern, Switzerland http://www.iam.unibe.ch/~wuyts/ Board Member of the European Smalltalk User Group: www.esug.org From renggli at student.unibe.ch Thu Feb 13 10:32:57 2003 From: renggli at student.unibe.ch (Lukas Renggli) Date: Thu, 13 Feb 2003 10:32:57 +0100 Subject: Idea : automatic information in templates In-Reply-To: Message-ID: <22BA7FD9-3F36-11D7-AC97-000393CFE6C8@student.unibe.ch> > And with the username, once we get users. I normally don't care about > the IP address of who changed the page :-) > >> What I would like to be able to say is for a given page that it get >> automatically time-stamped with the lats update. Everything you ask for is already there: Each time a new version of an structure-item is generated, the new version number, a time-stamp and the username (if available) is assigned. When you have a look at the version of a structure-item, you will see all this information presented there. If I am not wrong you should even see the date of the last change when editing a page. Cheers Lukas -- Lukas Renggli http://renggli.freezope.org From renggli at student.unibe.ch Thu Feb 13 10:32:57 2003 From: renggli at student.unibe.ch (Lukas Renggli) Date: Thu, 13 Feb 2003 10:32:57 +0100 Subject: Idea : automatic information in templates In-Reply-To: Message-ID: <22BA7FD9-3F36-11D7-AC97-000393CFE6C8@student.unibe.ch> > And with the username, once we get users. I normally don't care about > the IP address of who changed the page :-) > >> What I would like to be able to say is for a given page that it get >> automatically time-stamped with the lats update. Everything you ask for is already there: Each time a new version of an structure-item is generated, the new version number, a time-stamp and the username (if available) is assigned. When you have a look at the version of a structure-item, you will see all this information presented there. If I am not wrong you should even see the date of the last change when editing a page. Cheers Lukas -- Lukas Renggli http://renggli.freezope.org From roel.wuyts at iam.unibe.ch Thu Feb 13 10:42:23 2003 From: roel.wuyts at iam.unibe.ch (Roel Wuyts) Date: Thu, 13 Feb 2003 10:42:23 +0100 Subject: Idea : automatic information in templates In-Reply-To: <22BA7FD9-3F36-11D7-AC97-000393CFE6C8@student.unibe.ch> Message-ID: <73F7429A-3F37-11D7-B434-003065CC9F36@iam.unibe.ch> Hah, we are clearly spoiled by you :-) On Thursday, February 13, 2003, at 10:32 AM, Lukas Renggli wrote: >> And with the username, once we get users. I normally don't care about >> the IP address of who changed the page :-) >> >>> What I would like to be able to say is for a given page that it get >>> automatically time-stamped with the lats update. > > Everything you ask for is already there: Each time a new version of an > structure-item is generated, the new version number, a time-stamp and > the username (if available) is assigned. > > When you have a look at the version of a structure-item, you will see > all this information presented there. If I am not wrong you should > even see the date of the last change when editing a page. > > Cheers > Lukas > > -- > Lukas Renggli > http://renggli.freezope.org > > Roel Wuyts Software Composition Group roel.wuyts at iam.unibe.ch University of Bern, Switzerland http://www.iam.unibe.ch/~wuyts/ Board Member of the European Smalltalk User Group: www.esug.org From roel.wuyts at iam.unibe.ch Thu Feb 13 10:42:23 2003 From: roel.wuyts at iam.unibe.ch (Roel Wuyts) Date: Thu, 13 Feb 2003 10:42:23 +0100 Subject: Idea : automatic information in templates In-Reply-To: <22BA7FD9-3F36-11D7-AC97-000393CFE6C8@student.unibe.ch> Message-ID: <73F7429A-3F37-11D7-B434-003065CC9F36@iam.unibe.ch> Hah, we are clearly spoiled by you :-) On Thursday, February 13, 2003, at 10:32 AM, Lukas Renggli wrote: >> And with the username, once we get users. I normally don't care about >> the IP address of who changed the page :-) >> >>> What I would like to be able to say is for a given page that it get >>> automatically time-stamped with the lats update. > > Everything you ask for is already there: Each time a new version of an > structure-item is generated, the new version number, a time-stamp and > the username (if available) is assigned. > > When you have a look at the version of a structure-item, you will see > all this information presented there. If I am not wrong you should > even see the date of the last change when editing a page. > > Cheers > Lukas > > -- > Lukas Renggli > http://renggli.freezope.org > > Roel Wuyts Software Composition Group roel.wuyts at iam.unibe.ch University of Bern, Switzerland http://www.iam.unibe.ch/~wuyts/ Board Member of the European Smalltalk User Group: www.esug.org From renggli at student.unibe.ch Mon Feb 17 23:17:02 2003 From: renggli at student.unibe.ch (Lukas Renggli) Date: Mon, 17 Feb 2003 23:17:02 +0100 Subject: =?ISO-8859-1?Q?Re:_Feedback_zu_SmallNic_SmallWiki_Pr=E4sentation?= =?ISO-8859-1?Q?_vom_letzen_Samstag?= In-Reply-To: <3E101E980049E1BE@mail6.bluewin.ch> Message-ID: <8A731F0F-42C5-11D7-9178-000393CFE6C8@student.unibe.ch> Hallo Hannes, > Ich denke eine relativ einfache Addition k?nnte den "Verkaufswert" > f?r euer Wiki massiv erh?hen. Wenn ihr als Rendering-Option > den Export nach XML (SIXX * in Squeakmap) einbaut. > > Es d?rfte sich einfach darum handeln SIXX zu laden > und einige wenige Zeilen am richtigen Ort einzubauen > und ihr habt euren Export nach XML. SIXX hatten wir eigentlich schon ganz zu Beginn des Projektes als m?gliche Erweiterung im Auge. Gerade letzte Woche habe ich es dann integriert, weil ich es f?r die Pr?sentation ben?tigte. Es ist wirklich faszinierend, wie einfach und schnell man dieses Framework einbauen und nutzen kann. Leider scheint es aber Probleme beim Laden der XML-Daten zu geben (daran ist meine Pr?sentation fast gescheitert). Besonders bei den Byte-Arrays, welche ich verwende um die bin?ren Daten der Bilder abzulegen, dreht der XML-Parser durch und es treten sehr komische Fehler auf. Wir werden weiterhin mit SIXX arbeiten, die Bilder und andere bin?re Daten m?ssen aber in separaten Dateien abgelegt werden. Das ist zwar auch vom Platzbedarf her gesehen vorteilhaft, aber man kommt nicht mehr mit nur 3 Zeilen Code aus. > Das w?rde sicher auch einen guten CT-Artikel abgeben. Ja, das denke ich mir auch. Es gab ja vor kurzem einen Vergleich von verschiedenen Wiki-Implementationen im CT, leider wurde darin aber nicht auf die Smalltalk-Varianten eingegangen. Aber es ist dennoch gut zu wissen was die Konkurrenz kann > Dies also ein Feedback auf die interessante Demo vom letzten > Samstag Vielen Dank und liebe Gr?sse Lukas On Montag, Februar 17, 2003, at 08:46 Uhr, Hannes Hirzel wrote: > Hallo Lukas > > Obwohl ich vielleicht etwas desinteressiert deiner Pr?sentation gefolgt > bin, muss ich > im nachhinein sagen, dass mich das was ihr macht sehr interessiert. > > Ich bin auch gerne bereit ggfs. ein Alphaversion zu testen.... > > Der Gedanke im Smalltalk-Image drin ein komplette Objektnetz von > Dokumenten zu haben, die sich auf verschiedene Weise rendern > k?nnen ist wirklich faszinierend. > > Ich denke eine relativ einfache Addition k?nnte den "Verkaufswert" > f?r euer Wiki massiv erh?hen. Wenn ihr als Rendering-Option > den Export nach XML (SIXX * in Squeakmap) einbaut. > > Es d?rfte sich einfach darum handeln SIXX zu laden > und einige wenige Zeilen am richtigen Ort einzubauen > und ihr habt euren Export nach XML. > > Damit habt ihr dann sogar ein Autorensystem (Wiki-Syntax) > das XML produziert (ein Content Managemet System). > > Das w?rde sicher auch einen guten CT-Artikel abgeben. > > Dies also ein Feedback auf die interessante Demo vom letzten > Samstag > > Gr?sse und weiterhin 'happy squeaking' > > > Hannes Hirzel > > -------------------------------------------------------------- > * Mail zu SIXX von heute >> Date: Tue, 18 Feb 2003 00:55:17 +0900 >> From: "Masashi Umezawa" >> Subject: Re: port of prevayler >> To: "The general-purpose Squeak developers list" >> >> reply-to: The general-purpose Squeak developers list >> >> >> Hi, >> >>> Yes, much better. :-) We have one good language (Smalltalk) why not >>> use >>> it? All this focus on XML (in the IT industry over all that is) is >>> really tiresome. >> >> Tiresome, indeed. But I think SIXX has some advantages for serious, >> robust >> systems. >> >> - It automatically resolves circular or shared references. >> (In "do it" approach, you have to write it on your own). >> >> - It is safe. >> ("Do it" could be a security hall. You can insert dangerous >> expressions). >> >> - It is portable. >> (SIXX has been ported to 3 Smalltalks. It can be converted to other >> data >> structures by processing parsed dom tree). >> >> So I think it is oversimplified to say "much better". >> >> --- >> [:masashi | ^umezawa] -- Lukas Renggli http://renggli.freezope.org From hannes.hirzel.squeaklist at bluewin.ch Mon Feb 17 23:28:33 2003 From: hannes.hirzel.squeaklist at bluewin.ch (Hannes Hirzel) Date: Mon, 17 Feb 2003 23:28:33 +0100 Subject: =?ISO-8859-1?Q?Re:_Feedback_zu_SmallNic_SmallWiki_Pr=E4sentation?= =?ISO-8859-1?Q?_vom_letzen_Samstag?= Message-ID: <3E383FE10024623F@mail1.bluewin.ch> Salut Lukas Lukas Renggli wrote: > SIXX hatten wir eigentlich schon ganz zu Beginn des Projektes als > mögliche Erweiterung im Auge. Gerade letzte Woche habe ich es dann > integriert, weil ich es für die Präsentation benötigte. Es ist wirklich > faszinierend, wie einfach und schnell man dieses Framework einbauen und > nutzen kann. Schick doch bitte "Masashi Umezawa" ein Feedback mit diesem Inhalt. Er leistet eine gute Arbeit, kriegt aber nicht so viel Echo von der Liste. > Wir werden weiterhin mit SIXX arbeiten, die Bilder und andere binäre > Daten müssen aber in separaten Dateien abgelegt werden. Das ist zwar > auch vom Platzbedarf her gesehen vorteilhaft, Ist vom Nutzer / Betreiber-Standpunkt aus sehr gut! aber man kommt nicht mehr > mit nur 3 Zeilen Code aus. Ja, leider! Hoffentlich nicht allzuviel Mehrarbeit. Liebe Grüsse Hannes From renggli at student.unibe.ch Tue Feb 18 11:43:45 2003 From: renggli at student.unibe.ch (Lukas Renggli) Date: Tue, 18 Feb 2003 11:43:45 +0100 Subject: Meeting Today Message-ID: Hi, I'm not feeling very well, so I won't be able to come to the meeting today. But of course I am reachable by e-mail. I plan to do some heavy refactorings on the Structure hierarchy and update the tests today. I don't know how far I will get. What I plan to do is: - find a good way to map title to urls - include property management - move the template, title, ... i-vars to properties - create a management interface for properties BTW, do we want to be able to access properties directly "structure title" or only with special function calls like "structure propertyAt: #title"? Some further goals are (probably not for today): - attach the security-model - develop a more generic interface for storage Sorry for yesterday's e-mail in german: I discussed with Hannes about SIXX and how easy it is for a dump-out storage. As I already explained the XML-Parser gets messed-up when parsing very long ByteArrays (used to store resources). So I think the way to go is to store the resource-data as external binary files. I don't know yet if this solves the problems, but at least I hope so. Cheers Lukas -- Lukas Renggli http://renggli.freezope.org From ducasse at iam.unibe.ch Tue Feb 18 14:35:30 2003 From: ducasse at iam.unibe.ch (Stephane Ducasse) Date: Tue, 18 Feb 2003 14:35:30 +0100 Subject: Meeting Today In-Reply-To: Message-ID: > Hi, > > I'm not feeling very well, so I won't be able to come to the meeting > today. But of course I am reachable by e-mail. > Ok > I plan to do some heavy refactorings on the Structure hierarchy and > update the tests today. I don't know how far I will get. > > What I plan to do is: > - find a good way to map title to urls > - include property management > - move the template, title, ... i-vars to properties > - create a management interface for properties I'm thinking aloud: do we really want to have only properties? The distinction between an ivars and a property is that a property is optional? I have the impression that the important structural elements should be ivars. What do you think about that? > > BTW, do we want to be able to access properties directly "structure > title" or only with special function calls like "structure propertyAt: > #title"? I would prefer to use method structure title this way we do not see how they are encoded. But this means that we should have some way of creating method when you declare a new property and I do not like that. I prefer a static approach. So could we discuss before you change everything in the point 3 above (move template, title, ivars to properties)? > Some further goals are (probably not for today): > - attach the security-model > - develop a more generic interface for storage > > Sorry for yesterday's e-mail in german: I discussed with Hannes about > SIXX and how easy it is for a dump-out storage. As I already explained > the XML-Parser gets messed-up when parsing very long ByteArrays (used > to store resources). So I think the way to go is to store the > resource-data as external binary files. I don't know yet if this > solves the problems, but at least I hope so. But you should ask the vwnc mailing-list > > Cheers > Lukas > > -- > Lukas Renggli > http://renggli.freezope.org > > Prof. Dr. St?phane DUCASSE (ducasse at iam.unibe.ch) http://www.iam.unibe.ch/~ducasse/ "if you knew today was your last day on earth, what would you do different? ... especially if, by doing something different, today might not be your last day on earth" Calvin&Hobbes From renggli at student.unibe.ch Tue Feb 18 15:48:37 2003 From: renggli at student.unibe.ch (Lukas Renggli) Date: Tue, 18 Feb 2003 15:48:37 +0100 Subject: Meeting Today In-Reply-To: Message-ID: <0FCFA147-4350-11D7-808E-000393CFE6C8@student.unibe.ch> >> I plan to do some heavy refactorings on the Structure hierarchy and >> update the tests today. I don't know how far I will get. >> >> What I plan to do is: >> - find a good way to map title to urls >> - include property management >> - move the template, title, ... i-vars to properties >> - create a management interface for properties > > I'm thinking aloud: do we really want to have only properties? The > distinction between an ivars and a property is that a property is > optional? We will still have the following basic i-vars. These hold objects that need to be there in a valid object: Structure: id, parent, properties Chapter: children Page: document Resource: data, mimetype I think properties should be optional and be inherited on the instance side, e.g. if a component does not define a template or a storage the one from the parent will be taken or the default one if nothing is specified. In the current code the implementation of this behavior is duplicated several times. Another issue is the relation between the id and title. The id is used to the url from. Currently the title is generating a new id automatically whenever it changes. This has got the advantage that the url is always reflecting the page title, but there are also major drawbacks: - changing the title breaks your bookmarks to the page - titles have to be checked for validity (the id must be unique within a chapter) - special characters in titles make it hard to create links to that pags, as they could be used in wiki *Title>Page*. > I have the impression that the important structural elements should be > ivars. What do you think about that? I completely agree, the things that are needed to represent a page, a chapter or a resource are still in i-vars. I don't think that every component needs a title, so I would put this into the properties. >> BTW, do we want to be able to access properties directly "structure >> title" or only with special function calls like "structure >> propertyAt: #title"? > > I would prefer to use method structure title this way we do not see > how they are encoded. Yes I think we could write some simple accessors for the most often used properties like Structure>>title Structure>>storage Structure>>template ... and for the rest we would need to use Structure>>propertyAt: aSymbol > But this means that we should have some way of creating method when > you declare a new property and I do not like that. I prefer a static > approach. If we don't want the static approach, my idea would be doing it highly dynamic ;-) Structure>>doesNotUnderstand: aMessage (aMessage args size = 0) ifTrue: [ ^self propertyAt: aMessage selector ] (aMessage args size = 1) ifTrue: [ ^self propertyAt: aMessage selector put: aMessage args first ] ^super doesNotUnderstand > So could we discuss before you change everything in the point 3 above > (move template, title, ivars to properties)? I promised too much this morning: My headache has become worse and I cannot work on the computer such a long time. So we will have some more time to discuss and evaluate the possibilities :-) -- Lukas Renggli http://renggli.freezope.org From renggli at student.unibe.ch Wed Feb 19 08:29:51 2003 From: renggli at student.unibe.ch (Lukas Renggli) Date: Wed, 19 Feb 2003 08:29:51 +0100 Subject: have register to In-Reply-To: <04A4A2AA-43D8-11D7-B551-000393B2AA24@iam.unibe.ch> Message-ID: > http://scgwiki.iam.unibe.ch:8080/SCG/558 > > To reserve a slot for talking with ralph Friday Morning - SmallWiki (10:00am - 10:30am) I hope to get rid of that flu until friday, but I cannot promise anything. Cheers Lukas -- Lukas Renggli http://renggli.freezope.org From ducasse at iam.unibe.ch Wed Feb 19 19:09:32 2003 From: ducasse at iam.unibe.ch (Stephane Ducasse) Date: Wed, 19 Feb 2003 19:09:32 +0100 Subject: Meeting Today In-Reply-To: <0FCFA147-4350-11D7-808E-000393CFE6C8@student.unibe.ch> Message-ID: <4B80B2BC-4435-11D7-BEEF-000393B2AA24@iam.unibe.ch> Hi lukas I hope that you are going better. My mailbox just got the wonderfull idea to get desync from pop so I just got 6000 mails duplicated :) > We will still have the following basic i-vars. These hold objects that > need to be there in a valid object: > > Structure: id, parent, properties > Chapter: children > Page: document > Resource: data, mimetype > > I think properties should be optional and be inherited on the instance > side, e.g. if a component does not define a template or a storage the > one from the parent will be taken or the default one if nothing is > specified. In the current code the implementation of this behavior is > duplicated several times. OK > Another issue is the relation between the id and title. The id is used > to the url from. Currently the title is generating a new id > automatically whenever it changes. This has got the advantage that the > url is always reflecting the page title, but there are also major > drawbacks: > > - changing the title breaks your bookmarks to the page > - titles have to be checked for validity (the id must be unique within > a chapter) > - special characters in titles make it hard to create links to that > pags, as they could be used in wiki *Title>Page*. I did not really get it so you will explain us that. > I completely agree, the things that are needed to represent a page, a > chapter or a resource are still in i-vars. I don't think that every > component needs a title, so I would put this into the properties. I'm not sure that title should not be a iv of page if page has to have a title. There is a difference between an entity having a property and all the entities. > > Yes I think we could write some simple accessors for the most often > used properties like > > Structure>>title > Structure>>storage > Structure>>template > ... > > and for the rest we would need to use > > Structure>>propertyAt: aSymbol > >> But this means that we should have some way of creating method when >> you declare a new property and I do not like that. I prefer a static >> approach. > > If we don't want the static approach, my idea would be doing it highly > dynamic ;-) I would prefer to avoid that and do not mix meta stuff with the rest. > > Structure>>doesNotUnderstand: aMessage > (aMessage args size = 0) > ifTrue: [ ^self propertyAt: aMessage selector ] > (aMessage args size = 1) > ifTrue: [ ^self propertyAt: aMessage selector put: aMessage args > first ] > ^super doesNotUnderstand > >> So could we discuss before you change everything in the point 3 above >> (move template, title, ivars to properties)? > > I promised too much this morning: My headache has become worse and I > cannot work on the computer such a long time. So we will have some > more time to discuss and evaluate the possibilities :-) Rest well. Computers can wait. I hope you will be ok to see ralph johnson. Stef > > -- > Lukas Renggli > http://renggli.freezope.org > > Prof. Dr. St?phane DUCASSE (ducasse at iam.unibe.ch) http://www.iam.unibe.ch/~ducasse/ "if you knew today was your last day on earth, what would you do different? ... especially if, by doing something different, today might not be your last day on earth" Calvin&Hobbes From renggli at student.unibe.ch Wed Feb 19 22:23:54 2003 From: renggli at student.unibe.ch (Lukas Renggli) Date: Wed, 19 Feb 2003 22:23:54 +0100 Subject: Meeting Today In-Reply-To: <4B80B2BC-4435-11D7-BEEF-000393B2AA24@iam.unibe.ch> Message-ID: <72AEAAFD-4450-11D7-BC4E-000393CFE6C8@student.unibe.ch> > I hope that you are going better. Yep, a little bit. > My mailbox just got the wonderfull idea to get desync from pop so I > just got 6000 mails duplicated :) Arghhhh ... >> Another issue is the relation between the id and title. The id is >> used to the url from. Currently the title is generating a new id >> automatically whenever it changes. This has got the advantage that >> the url is always reflecting the page title, but there are also major >> drawbacks: >> >> - changing the title breaks your bookmarks to the page >> - titles have to be checked for validity (the id must be unique >> within a chapter) >> - special characters in titles make it hard to create links to that >> pags, as they could be used in wiki *Title>Page*. > > I did not really get it so you will explain us that. Ok, I will try to do so. >>> But this means that we should have some way of creating method when >>> you declare a new property and I do not like that. I prefer a static >>> approach. >> >> If we don't want the static approach, my idea would be doing it >> highly dynamic ;-) > > I would prefer to avoid that and do not mix meta stuff with the rest. I do not understand what you mean by "meta stuff", but I also prefer not to use the message #doesNotUnderstand: >>> So could we discuss before you change everything in the point 3 >>> above (move template, title, ivars to properties)? >> >> I promised too much this morning: My headache has become worse and I >> cannot work on the computer such a long time. So we will have some >> more time to discuss and evaluate the possibilities :-) > > Rest well. Computers can wait. I played a bit around with the different approaches. We should discuss about it. Everything is in StORE, so we will be able to go back to any older version :-) > I hope you will be ok to see ralph johnson. I hope so too. Do I have to prepare something? Cheers Lukas -- Lukas Renggli http://renggli.freezope.org From renggli at student.unibe.ch Thu Feb 20 14:36:22 2003 From: renggli at student.unibe.ch (Lukas Renggli) Date: Thu, 20 Feb 2003 14:36:22 +0100 Subject: [SIXX] feedback Message-ID: <4D297AC3-44D8-11D7-ADB1-000393CFE6C8@student.unibe.ch> Hi Masashi, I am currently developing a new Smalltalk Wiki implementation (http://scgwiki.iam.unibe.ch:8080/SCG/520) and I am planning to use SIXX to store my large tree-structures to xml. It seems to me the perfect solution, because it can handle circular references and it dialect independent. My first attempt was to dump everything out into a XML file using the following code from your tutorial: sws := SixxWriteStream newFileNamed: 'root.xml'. sws nextPut: wikiRootNode. sws close. The XML file looks fine, but unfortunately the XML parser is not able to read that file again. The problem seems to be the huge binary data (images, pdf) that is stored within ByteArray's. I think storing binary-data to XML is not a good idea anyway, so I want them to be put in special external files. The only thing to change - at least I think so - is my Resource class, that contains this binary data. So it should only dump the filename of the binary data and not the data itself. To archive this goal, I wrote something similar to: Resource>>sixxContentOn: aStream indent: level context: dictionary | filename | filename := self generateUniqueFilename. self dumpToBinaryFile: filename. super sixxContentOn: aStream ident: level context: dictionary But how do I prevent SIXX from saving the binary data again, without hardcoding the other i-vars? How do I archive the loading of the binary data? Could you give me some hints? Thanks a lot for your help Lukas -- Lukas Renggli http://renggli.freezope.org From markus.gaelli at iam.unibe.ch Thu Feb 20 15:06:20 2003 From: markus.gaelli at iam.unibe.ch (=?ISO-8859-1?Q?Markus_G=E4lli?=) Date: Thu, 20 Feb 2003 15:06:20 +0100 Subject: [SIXX] feedback In-Reply-To: <4D297AC3-44D8-11D7-ADB1-000393CFE6C8@student.unibe.ch> Message-ID: <7C82DEAE-44DC-11D7-9957-0003938AC0F4@iam.unibe.ch> Am Donnerstag, 20.02.03 um 14:36 Uhr schrieb Lukas Renggli: > Hi Masashi, > > I am currently developing a new Smalltalk Wiki implementation > (http://scgwiki.iam.unibe.ch:8080/SCG/520) and I am planning to use > SIXX to store my large tree-structures to xml. It seems to me the > perfect solution, because it can handle circular references and it > dialect independent. > > My first attempt was to dump everything out into a XML file using the > following code from your tutorial: > > sws := SixxWriteStream newFileNamed: 'root.xml'. > sws nextPut: wikiRootNode. > sws close. > > The XML file looks fine, but unfortunately the XML parser is not able > to read that file again. The problem seems to be the huge binary data > (images, pdf) that is stored within ByteArray's. > > I think storing binary-data to XML is not a good idea anyway, so I > want them to be put in special external files. Hi Lukas and Masashi, I really like to be able to store binary data in the xml-file very much (I wasn't aware of that functionality of SmaCC), so at least please keep it for me (and certainly fix it if necessary and possible :-), as I want to make heavy use out of it in the near future. Thanks, Markus > The only thing to change - at least I think so - is my Resource class, > that contains this binary data. So it should only dump the filename of > the binary data and not the data itself. To archive this goal, I wrote > something similar to: > > Resource>>sixxContentOn: aStream indent: level context: dictionary > | filename | > filename := self generateUniqueFilename. > self dumpToBinaryFile: filename. > super sixxContentOn: aStream ident: level context: dictionary > > But how do I prevent SIXX from saving the binary data again, without > hardcoding the other i-vars? How do I archive the loading of the > binary data? > > Could you give me some hints? > > Thanks a lot for your help > Lukas > > -- > Lukas Renggli > http://renggli.freezope.org > From umejava at mars.dti.ne.jp Sat Feb 22 15:28:19 2003 From: umejava at mars.dti.ne.jp (Masashi Umezawa) Date: Sat, 22 Feb 2003 23:28:19 +0900 Subject: [SIXX] feedback References: <7C82DEAE-44DC-11D7-9957-0003938AC0F4@iam.unibe.ch> Message-ID: <005901c2da7e$bbd5a330$0200a8c0@qwerty> Hi Markus and Lukas, > Hi Lukas and Masashi, > > I really like to be able to store binary data in the xml-file very much > (I wasn't aware of that functionality of SmaCC), > so at least please keep it for me (and certainly fix it if necessary and > possible :-), as I want to make heavy use out of it in the near future. > Currently SIXX serializes binary data in a rather naive format like this: #( 1 2 3 4 5 ) It is sufficient for small data. But of course it is not so well if the data is big. The best solution I think is to zip the data and write it in base64 format. Actually, in the SixxMorphMemento example (included in SIXX for Squeak - maybe you are using SIXX for VW?), I use the method. (It is also a sample of not adding 'sixx*' methods to existing classes, but ignore this aspect). In the sample, very complex object (morph) is stored in XML. But its downside is portability. There is no standard way in current Smalltalks to make the binary data zipped (or base64). So if you use this solution, your code will not run in other Smalltalks. (like my SixxMorphMemento example). But if you really have needs to do it in a portable manner, you can add some indirect layer to achieve this by writing wrapper classes. Cheers, --- [:masashi | ^umezawa] From umejava at mars.dti.ne.jp Sat Feb 22 14:54:15 2003 From: umejava at mars.dti.ne.jp (Masashi Umezawa) Date: Sat, 22 Feb 2003 22:54:15 +0900 Subject: [SIXX] feedback References: <4D297AC3-44D8-11D7-ADB1-000393CFE6C8@student.unibe.ch> Message-ID: <005801c2da7e$bba607b0$0200a8c0@qwerty> Hi Lukas, ----- Original Message ----- > I am currently developing a new Smalltalk Wiki implementation > (http://scgwiki.iam.unibe.ch:8080/SCG/520) and I am planning to use > SIXX to store my large tree-structures to xml. It seems to me the > perfect solution, because it can handle circular references and it > dialect independent. Great! > But how do I prevent SIXX from saving the binary data again, without > hardcoding the other i-vars? How do I archive the loading of the binary > data? I feel it is best to explain in code. So I attached the sample. The sample is Squeak file-in format but you can read it by text editor. Basically, in #sixxContentOn:indent:context:, you can delegate the writing process to some of the children (inst-vars) by using #sixxOn:name:indent:context:. Resource>>sixxContentOn:indent:context: | id newLevel fileStr | "Write ID to XML instead of binary data" newLevel := level + 1. aStream cr. id := self generateID. id sixxOn: aStream name: 'resourceID' indent: newLevel context: dictionary. "Write some other inst vars (optional)" self name sixxOn: aStream name: 'name' indent: newLevel context: dictionary. "Dump actual data to file" [fileStr := FileStream forceNewFileNamed: id. fileStr nextPutAll: binaryData asArray printString. "just a sample - you should use binary mode"] ensure: [fileStr close.] For the reading, you can override #sixxInstVarNamed:put: Resource >>sixxInstVarNamed:put: instVarName = 'resourceID' ifTrue: [ | fileStr | [fileStr := FileStream readOnlyFileNamed: aValue. self binaryData: (Array readFrom: fileStr contents) asByteArray] ensure: [fileStr close.]. ^self. ]. instVarName = 'name' ifTrue: [^self name: aValue]. There are other "hook" methods in SIXX for the more efficient serialization/deserialization. But I think the sample code fits your purpose. I hope it helps. Please feel free to ask me, if you have some questions. I'm looking forward to SmallWiki! --- [:masashi | ^umezawa] -------------- next part -------------- A non-text attachment was scrubbed... Name: SIXX-ResourceExample.st Type: application/octet-stream Size: 4740 bytes Desc: not available Url : http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20030222/2c1a22b9/SIXX-ResourceExample.obj From renggli at student.unibe.ch Sun Feb 23 19:06:50 2003 From: renggli at student.unibe.ch (Lukas Renggli) Date: Sun, 23 Feb 2003 19:06:50 +0100 Subject: [SIXX] feedback In-Reply-To: <005801c2da7e$bba607b0$0200a8c0@qwerty> Message-ID: <94B9AEF8-4759-11D7-8F80-000393CFE6C8@student.unibe.ch> Hi Masashi, > I feel it is best to explain in code. So I attached the sample. > The sample is Squeak file-in format but you can read it by text editor. Thanks a lot for the sample-code! It helped me a lot to finish implementing the storage within a few minutes. SIXX does work perfectly now, even with very big trees and several megabytes of binary data. > I'm looking forward to SmallWiki! There will be a first public version soon, but there are still some things that have to be finished and cleaned up before. Cheers Lukas -- Lukas Renggli http://renggli.freezope.org From ducasse at iam.unibe.ch Fri Feb 7 15:37:53 2003 From: ducasse at iam.unibe.ch (Stephane Ducasse) Date: Fri, 07 Feb 2003 15:37:53 +0100 Subject: Smalltalk Lectures Message-ID: Hi all so I will do normally the lectures on Smalltalk during the summer semester, at the place of the interpreter model lectures. This way we will have one lecture in summer and one lectures in winter. I will send an announce soon when the schedule will be finalized. Lukas we will have to discuss because I want them to understand, write Unit tests, extend, SmallWiki. Stef I will start to check in which status is my current migration to powerpoint is. and let you know. Prof. Dr. St?phane DUCASSE (ducasse at iam.unibe.ch) http://www.iam.unibe.ch/~ducasse/ "if you knew today was your last day on earth, what would you do different? ... especially if, by doing something different, today might not be your last day on earth" Calvin&Hobbes From renggli at student.unibe.ch Fri Feb 7 20:32:04 2003 From: renggli at student.unibe.ch (Lukas Renggli) Date: Fri, 07 Feb 2003 20:32:04 +0100 Subject: Smalltalk Lectures In-Reply-To: Message-ID: Hi St?phane, > I will send an announce soon when the schedule will be finalized. > Lukas we will have to discuss because I want them to understand, write > Unit tests, extend, SmallWiki. do I understand correctly, that you will already use SmallWiki in the coming summer-term? My plan for the next month is to finish implementing the core and to get rid of the informatics project, but not of SmallWiki of course. What is left to do for a working and usable implementation is: - storage: basic interface, xml - security: permissions, server authentication, management screens - resources: images, files, ... - testing the html user-interface And of course I also have to write a paper or something. I think we should discuss about all that at the next meeting. Will we meet as usual the next week? Cheers Lukas -- Lukas Renggli http://renggli.freezope.org