08:52PM <cdegroot> lukas - I'm currently on a turning point. Either keep current 'Gardner' as a simple embeddable Wiki component (almost there), or continue porting SmallWiki stuff. Do you guys have any plans for a SmallWiki Seaside port? 09:03PM > we don't have concrete plans right now 09:04PM <cdegroot> (and no time, probably ;-)) 09:04PM > however there are some points that we want for SmallWiki 2 09:04PM > one of them is the Seaside port 09:04PM > yes, my time is very limited right now 09:06PM <cdegroot> ah. I'm currently looking at things like user authentication/rights, and I need to decide where to place that kind of stuff, etcetera. So I'm hopping on two thoughts: either keep 'ripping' SmallWiki components, or cook things up myself. 09:07PM > well I don't see there is much sense to make a 1:1 port of SmallWiki to Seaside/Squeak 09:07PM <cdegroot> probably not, no. 09:07PM <cdegroot> oh well, I think I'll create a separate 'userdb' component (read up on Zope's interfaces etcetera) and see where it goes from there... 09:08PM > so if you like, we might do a slight (this means not an 1:1 port) together (in my rare spare time ;-) ) 09:08PM > well as you have certainly seen I have taken a lot of ideas from zope 09:08PM <cdegroot> well, that'd mean that your rare spare time would have to overlap with my rare spare time ;-). 09:09PM > :-) 09:09PM > but copying zope is not my goal 09:09PM > also there are a lot of problems with this 09:09PM <cdegroot> furthermore, I'm probably not of much use to you - although I grok the ideas behind Seaside reasonably well, I'm a bit behind with the concrete implementation. 09:09PM > because zope is heavily basing on multiple inheritance 09:09PM <cdegroot> my goal is a 'white box' component toolkit. 09:10PM <cdegroot> no through-the-web software building nonsense (the absolutely worst idea of Zope) 09:10PM > but around a 'white box' a black box might be easily built :-D 09:10PM <cdegroot> yup. But not be me (at least not now). 09:11PM > well, i do not agree completely 09:11PM <cdegroot> So 'Gardner' is a component (ok, not yet), and my other pet project, 'Sagan', is the substrate underneath: persistence, interfaces for authentication etcetera, ... 09:11PM <cdegroot> at least, that's where I think I'm going. 09:11PM > sometimes it is quite usefull to have a web-editing stuff ... 09:11PM > see WABrowser 09:11PM > for some things this is a hit ! 09:12PM <kencausey> I agree, sometimes you have a customer who just needs to make an occasional change to a page. 09:12PM <cdegroot> well, having developed a couple of hefty things in Zope, I can tell you that it is unwise to make it the *only* mode ;-) 09:12PM > http://www.ahl.unibe.ch is a zope page i made ;-) 09:12PM <kencausey> Agreed, zope external editor is the best thing since sliced bread. 09:12PM <cdegroot> kencausey: occasionally editing a page is decidedly something different from building a shop through-the-web. 09:12PM > i am interfacting now with seaside 09:13PM <kencausey> But both dtml and ZPT makes me hack up a hairball after I spend time in Squeak. 09:13PM <cdegroot> yup 09:13PM > but i started with it before I knew smalltalk 09:13PM <cdegroot> where I'm going is a white-box toolkit for programmers, including all the tools (like a Wiki) that allows end-users to configure bits. 09:13PM <kencausey> Same here more or less, lots of prehistory with python at least. 09:13PM <cdegroot> ditto for me, btw 09:14PM > ohh, it feels like in a python irc-chat ;-) 09:14PM <cdegroot> haven't used python for at least a year. 09:15PM <cdegroot> it falls by the wayside - complex things I do in Smalltalk, simple things in bash/sed/awk/... 09:15PM > so with SmallWiki I tried to make something similar to Zope (nesting, different components, ...), but not to copy the bad things and to stay with the easiness of Wikis 09:16PM > right now there is still a lot of handwork to do 09:16PM > but that will change, especially with Seaside 09:16PM <cdegroot> 'component' is a completely different concept in Seaside... 09:17PM > yes, I talked about a component in the sense of zope 09:17PM <cdegroot> ok, so 1:1 port of SmallWiki is useless. I'll let myself be inspired by it, then. 09:17PM <cdegroot> First and foremost, I need some authentication model... 09:17PM <cdegroot> (and I'm heavily leaning towards capabilities) 09:18PM > Stéphane is using SmallWiki in Smalltalk-Lectures here at Bern and the students write (zope-)components as exercise ;-) 09:18PM > when implementing the security-model i had a look at capabilites 09:18PM <cdegroot> yeah, that's the nice thing of teaching - students available to extend whatever you like to be extended ;-) 09:19PM > but it was too complex for me 09:19PM <cdegroot> it is not very complex, however management can be hard. 09:19PM > i did not found good examples/documentation 09:19PM > so i decided to go with a unix like security 09:19PM <cdegroot> essentially, you have a sort of keyring for every user, with lots and lots of keys on it. 09:20PM <cdegroot> (if you see every cap as a key to unlock a single 'door') 09:20PM > a door might be 'editing a specific page'? 09:20PM <cdegroot> yup. 09:20PM > or 'editing editing any page'? 09:20PM <cdegroot> also 09:21PM <cdegroot> whatever you want :-) 09:21PM <cdegroot> so you could give a trusted user an 'edit any page' capability, which basically would be a key to unlock a key-box. The key-box would hold capabilities for all the pages to edit them. 09:21PM <cdegroot> (or, rather, produce them on-the-fly). 09:22PM > ok 09:22PM <cdegroot> a less trusted user might receive capabilities on specific pages. 09:22PM > yes, or if you have folder, it would mean that he might edit only a subtree of the wiki 09:23PM <cdegroot> well, if you let that sort of stuff inherit. 09:23PM > and what if you only want to let users edit pages that they created themselves? 09:23PM <cdegroot> but the basic idea is that every combo 'object/message' is protected by a capability. On top of that, you can have capabilities that help you to access other capabilities, etcetera. 09:24PM <cdegroot> That's easy enough, because if you create something you usually receive full capabilities on them. 09:24PM <cdegroot> In fact, the only way to get a capability is to get it from someone else or to create the object (basically) 09:25PM > so implementation would be with a keyring class containing a set of keys 09:25PM > so how do you check the capabilities when executing messages 09:25PM <cdegroot> You don't - capabilities *are* the message sends. 09:25PM > you don't want to have to check in each and every message manually, no? 09:26PM > but this looks odd 09:26PM <cdegroot> so if you don't have a capability, you simply don't have a way to express the action. 09:26PM > so you have to send all the messages to your keyring 09:26PM > how would this look in smalltalk? 09:26PM <cdegroot> no, to the capabilities. 09:26PM <cdegroot> well, you never see the original object. 09:27PM <cdegroot> only capabilities on the original object. 09:27PM > so you need to work with symbols? 09:27PM > message-sends? 09:27PM <cdegroot> (which, internally, holds a pointer to the object you cannot access and implements #dnu to forward a selected set of messages). 09:27PM <cdegroot> no, you just say 'someObject foo' 09:27PM > so you have proxies around everything? 09:27PM <cdegroot> but someObject is not the real object, it is your capability on the object. 09:28PM <cdegroot> yup, basically secure proxies. 09:29PM > so every user wraps with its own proxies, this means quite a heavy overhead, no? 09:29PM > and how is the wrapping done? 09:29PM > all results of a message send has to be wrapped, no? 09:29PM <cdegroot> lots of ways are possible. Easiest is by just storing the proxies. 09:31PM <cdegroot> you need some sort of interaction between your keyring and the storage in order to fetch object wrapped inside the correct capabilities, but basically that's all doable. 09:32PM > yeah, but also if you get return values from your wrapped object you have to wrap them ... 09:32PM > when returning collection you even have to do a deep-wrap ;-) 09:33PM <cdegroot> unless of course your keyring expresses your whole view of the database. Then you're done - you just operate on your keyring. 09:34PM > do you know any smalltalk examples of such an implementation? 09:34PM <cdegroot> nope. 09:34PM > i have only found Java and E implementations :-( 09:34PM <cdegroot> yup 09:34PM <water> squeak-E is getting close 09:35PM > ahh, didn't know about that 09:35PM <cdegroot> water: I thought E-language-on-top-of-Squeak was furthest, not? 09:35PM <cdegroot> (as opposed to 'E-zen applied to Squeak') 09:35PM <water> cdegroot: he asked about smalltalk :P 09:36PM <cdegroot> anyway, if your keyring presents your view of the database it becomes remarkably simple. Just another OODB. 09:36PM <water> cdegroot: and it's not E-language-on-top-of-squeak 09:36PM <water> cdegroot: it's E-concepts-embedded-in-squeak 09:37PM <smakbo> water: is this all happening offline? 09:37PM <cdegroot> so the language would be Smalltalk? 09:37PM <smakbo> I'm subscribed to the Squeak-E list, but haven't seen any activity for quite a while 09:37PM <water> is what happening offline? the main author of it is Rob Withers, who is "quotar" here 09:37PM <smakbo> ok 09:38PM <water> cdegroot: no, the language would be smalltalk modified to better support the E model. just like AspectS isn't Smalltalk but is an extension to support AspectJ concepts 09:39PM <cdegroot> yeah - that's what I meant. 09:39PM <cdegroot> Smalltalk ;-) 09:39PM <cdegroot> For Some Value Of Smalltalk[tm] 09:39PM * water rolls his eyes 09:39PM <cdegroot> I thought that one project was actually porting E on top of the Squeak VM. 09:40PM <water> that's what the E fellows were considering 09:40PM <cdegroot> and that one was going reasonably well. But can't remember - I've been so busy the past ~6 months that I only have vaguely followed all this. 09:40PM <water> that's a total unknown 09:40PM <water> if you don't know, don't say 09:40PM <water> :P 09:41PM <cdegroot> anyway, lukas - try to think about modelling a zope-like 'content database' with just caps. Probably after reading up http://www.skyhunter.com/marcs/ewalnut.html#SEC41 - it's an interesting exercise, and I think it is doable. 09:43PM <cdegroot> caps would probably be modelled basically by keyboxes - probably a better metaphor than keyrings. 09:43PM <cdegroot> your password unlocks your keybox. In it are keys directly to 'content objects', but probably also references to other keyboxes. 09:44PM <cdegroot> For example, everyone would have a key to the 'anonymous' keybox, a) to access all the objects in there, and b) to add stuff in there. 09:44PM <cdegroot> etcetera. 09:44PM > that sounds reasonable to have a kind of composite ... 09:44PM > of keyboxes 09:44PM > thanks for the link, but the java examples, arghhhh ... 09:44PM > ok, i won't complain ;-) 09:45PM <cdegroot> when you create an object, you stash the naked object in your keybox and add some basic capabilities to other keyboxes - that'd constitute publishing. 09:45PM <cdegroot> not java, the examples are in E 09:45PM > yeah, you are right of course, but it's quite close to java ;-) 09:46PM <cdegroot> for some cases you probably would need some way of amplifying caps - if you have a cap on A and you also hand it a cap on B, you might get a more powerful cap on A (or C) back. 09:46PM <cdegroot> lukas: I will not forward that comment to E's author. He might take offense... *** fragment joined channel #squeak at 09:46PM 09:47PM > why not? 09:47PM <cdegroot> because most of his writings contain passages about how bad Java is ;-) 09:48PM > really? but why did he stick to that kind of style? 09:48PM <cdegroot> it's curlybraces style, but quite far removed from Java I think. 09:49PM > anyway, the text about capabilities I read half a year ago was with java-examples 09:49PM <cdegroot> if you have 'class' as a keyword and '{}' as delimiter, it's hard not to be compared with Java ;-) 09:49PM > and it was painful trying to understand ... 09:49PM > or C++ 09:49PM <cdegroot> E is actually quite a nice language. Too bad there's no IDE, class browser, .. for it, b/c I don't do languages without them anymore. 09:50PM <cdegroot> and it runs on top of Java :-( 09:50PM > yeah i know 09:50PM > why have they taken the java-vm and not dot-net or squeak or ... 09:51PM <cdegroot> anyway, in a web environment this whole capability thingy would be perfectly secure. With a locally-connected Squeak image, it'd become risky (not with a remote image in a client-server configuration) - you'd need Squeak-E for the latter to work. 09:51PM <cdegroot> I think at the time the JavaVM was most readily available. 09:52PM > i see and it is probably also possible to mix java and E, no? 09:52PM <cdegroot> yeah, but probably not with full security :-) 09:52PM > i once read an article how to wrap the FileStreams of Java with E ... 09:53PM > there are some drawbacks of course ... 09:53PM > but that doesn't bother us ;-) 09:53PM <cdegroot> nope. 09:56PM <cdegroot> anyway, I think I'll give it a shot. At least I'll be able to say "I tried it..." 09:56PM > cool, I am looking forward hearing from your experiences and seeing the code 09:57PM <cdegroot> me too.... 09:57PM * cdegroot looks over shoulder. Sh*t, nobody there 09:59PM <cdegroot> only issue is that I probably need a good OODB underneath. 09:59PM <cdegroot> so, next question (is the group still with me? guys?): Magma fit enough already? 09:59PM > yeah, lets come back to this issue ... 10:00PM > it would be cool to have something that does versions automatically ... *** efc joined channel #squeak at 10:00PM 10:00PM <cdegroot> versions? 10:00PM <cdegroot> (a bit overloaded term. Please specify :-)) 10:00PM > like the zope-db, something of zope that is think is really cool 10:01PM > and also quite secure, i've never heard of a zope-db-crash so far 10:01PM <efc> Whats the address of the channel stats page thingy ? 10:01PM > am I talking too much? 10:01PM <efc> I think I know the server, but can't remember the page hehe 10:01PM <efc> You're not taking my spot lukas! 10:02PM * water indicates the topic 10:02PM <efc> oh hehe 10:02PM <cdegroot> Zope DB is basically image+changelog :-) 10:02PM <efc> Who reads topics anyway.. 10:03PM <cdegroot> (strike that smiley, on second thought) 10:04PM <cdegroot> lukas: it is impossible to 'crash' a transaction log. 10:04PM > yes, it is similar to PrefLayer or what was its name? 10:04PM <cdegroot> Prevayler. That's really image+changelog. Zope is actually just changelog. 10:04PM > yeah ... 10:04PM > zope is only appending 10:05PM > so in the worst case if something goes wrong 10:05PM > you just cut the file 10:05PM > and have something valid again 10:05PM <cdegroot> yup. Downside: GC is necessary. But we have a >1Gig ZEO db in production for almost two years now, never a problem. 10:05PM > although this is rarely needed, i 've never needed to do it so far 10:05PM > yeah 10:06PM <cdegroot> biggest issue that kept me from writing one is a *fast* marshaller. 10:06PM > but gc is easy, you just copy everything to a new file ... 10:06PM <cdegroot> no doubt about it ;-) 10:07PM <cdegroot> so, SRP, (Smart)RefStreams, ... - what would be a good cPickle equivalent in Squeak? 10:07PM > well I've never used SRP 10:08PM > and I doubt that RefStreams work, as you have to keep the references somehow up-to-date 10:09PM <cdegroot> references are always backwards in the file, so you don't need to keep much up-to-date. 10:10PM > yeah but if you save a page, you don't want that the whole wiki is coming with it. so how do you handle that? 10:10PM <cdegroot> cPickle lets you place methods on classes to replace a 'serialize-by-value' with a 'serialize-by-ref'. That's a vital component. 10:11PM > ok, that is cool. so do you think that we could use SmartRefStreams to write to a Zope-DB like file? 10:12PM <water> and cPickle works on block closures and languages with full GC's? 10:12PM <cdegroot> dunnow - I think it's a tad slow. 10:12PM <cdegroot> water: dunnow about the full GC bit, but python has no block closures ;-) 10:12PM <water> cdegroot: right. so basically it's the same broken pickle concept from python 10:13PM <cdegroot> cPickle = pickle 10:15PM <cdegroot> water - it might be broken in some ways, but it works fine, is fast, and supports a lot of awfully useful tools. 10:16PM <cdegroot> but blocks do complicate matters, yes. 10:16PM <water> cdegroot: well then use magma 10:16PM > i do not get that, why do they complicate? 10:17PM <water> because they need to be lexical closures of at least some kind 10:17PM <water> over their environment 10:17PM <cdegroot> water: I'm a bit (a lot) worried about all the statements in the Magma docs re. the speed of collections. *** dvf joined channel #squeak at 10:18PM 10:18PM <water> hi daniel 10:18PM <cdegroot> hi dvf 10:18PM <smakbo> hey d 10:18PM <water> cdegroot: well, you can worry until you're blue in the face, or figure out how to improve it yourself instead of rolling another pickle solution 10:19PM <cdegroot> oh, you're right there. However, it'd be nice if there would be something akin to pickle for Squeak. Magma is not always what you want... 10:20PM <water> nothing is ever always what you want 10:21PM <cdegroot> Furthermore, I'm looking at something to build commercial projects on. A totally unproven OODB which is highly complex is not something I am going to recommend to customers. Something ZODB-like, where you can almost prove that you won't lose data, I'd do a lot quicker. 10:22PM <cdegroot> (something that would stash everything in MySQL without me having to break my head over the O/R gap, even quicker ;-)) 10:22PM <efc> Are customers in Europe more willing to look at non-"standard" solutions (not Microsoft and not Java) ? 10:23PM <cdegroot> Depends on the customer and the sort of solution. 10:23PM <cdegroot> If I build a website and I say 'Linux, MySQL, Apache, and <something>', most of them will not really care (or know) about the difference between something=PHP, Python, Perl, or Squeak. -- Lukas Renggli http://renggli.freezope.org