Hopbot log for 2007-12-09 - Helma IRC channel: #helma on irc.freenode.net

2007-12-09:

[4:58] <midnightmonster> helma.Http doesn't populate getUrl().content when method is PUT
[5:04] <midnightmonster> no, that's not it... actually helma.Http doesn't set getUrl().content unless the http response code is 200. that's really, really dumb.
[5:12] <midnightmonster> bug field
[5:12] <midnightmonster> filed, too
[5:47] <midnightmonster> turns out to involve Weirdness(tm). see http://helma.org/bugs/show_bug.cgi?id=583 if you care
[6:08] <midnightmonster> weirdness tracked down. see bug.
[7:30] * zumbrunn wonders why there was no automatic notification of this bug sent to the helma-dev list
[7:34] <zumbrunn> already bug 582 seems to have gotten stuck somewhere http://helma.org/bugs/show_bug.cgi?id=582
[14:03] <midnightmonste1> i sent a msg to helma-user last night and it hasn't gone out either. problem with the mail server/mailing lists?
[14:03] <midnightmonste1> oh. and my bug is gone
[14:04] <midnightmonste1> crap
[14:05] <midnightmonste1> oh, no. nevermind. 583 is still there. what's with 582?
[14:05] <midnightmonste1> back to my first theory about the mailing list/server
[14:07] <zumbrunn> right, the mail list server seems to have a problem
[14:07] <zumbrunn> something hannes will have to take a look at
[14:08] <zumbrunn> 582 just proves that the problem already started on friday
[14:27] <midnightmonster> who do we bug to check the mail server?
[14:29] <zumbrunn> hannes is gonna have to look into it
[14:29] <zumbrunn> he has access to it
[14:30] <midnightmonster> so are you going to bug him, or should I?
[14:31] <zumbrunn> I'll bug him as soon as he comes online
[14:31] <midnightmonster> ok
[14:33] <midnightmonster> http://helma.pastebin.com/f7082c07e <-- I ported the simple js lib for working with couchdb from AJAX and crockford's json to helma.http and helma's json support.
[14:34] <midnightmonster> but you need the fixes to helma.Http in my bug to use it
[14:37] <zumbrunn> very cool
[14:37] <zumbrunn> looking at it
[14:44] <zumbrunn> btw, should we change the helma lib to use crockfords new JSON2 code?
[14:44] <midnightmonster> dunno. I didn't know there was JSON2
[14:44] <midnightmonster> looking now
[14:44] <zumbrunn> http://creativecommons.org/licenses/by/3.0/
[14:45] <zumbrunn> http://www.json.org/json2.js
[14:46] <zumbrunn> I'm also wondering how we should best include further modules like this with helma
[14:47] <zumbrunn> jala will be included in 1.7
[14:47] <zumbrunn> or already in 1.6.1, actually
[14:48] <zumbrunn> the original idea of the helma.xxxx stuff was to tuck everything away in one namespace
[14:48] <midnightmonster> I think the only/major change is that he's moved the functions to JSON.stringify and JSON.parse instead of Object.toJSONString and Object.parseJSON. that's important in standard javascript but not rhino/helma. I think maybe we should have both so folks can use whatever they're used to
[14:48] <zumbrunn> and to generally not directly use it from there
[14:49] <midnightmonster> ?
[14:49] <zumbrunn> and instead first copy a reference into the global scope or wherever
[14:49] <zumbrunn> the helma prefix wasn't the most ideal choice for that
[14:50] <midnightmonster> why would one do that? helma.Http is perfectly understandable. if I make a reference to it then I have to remember later where I got it from
[14:50] <zumbrunn> now we'll already have "helma" and "jala" as separate prefixes
[14:50] <midnightmonster> ok
[14:50] <zumbrunn> so, not sure if we should give up on the original idea or what
[14:52] <zumbrunn> bbl
[14:52] <midnightmonster> in the client side world, you're supposed to "namespace" your lib a lot like we're doing now with jala, etc..
[14:53] <midnightmonster> only question is where would stuff like this couchdb script go.
[15:06] <zumbrunn> in the context of helma and the server-side, I see two advantages of tucking everything away in namespaces *and* copying references into the scope where the code is actually needed...
[15:07] <zumbrunn> one is the benefit of abstracting the implementation away from where it is used
[15:07] <zumbrunn> the other is that the core framework becomes more flexible and it is easier to evolve while maintaining backwards/forwards compatibility
[15:08] <zumbrunn> for example, with helma.File being backwards compatible with the old built-in File object...
[15:09] <zumbrunn> we could drop the built-in File object and old apps could continue to run as is by copying helma.File into the global scope
[15:09] <zumbrunn> File = helma.File
[15:11] <midnightmonster> (only don't do that, bcause, though prettier, helma.File is still amazingly slower than File)
[15:11] <zumbrunn> right
[15:13] <zumbrunn> there are also those that argue that wrapping java apis in js prototypes isn't worth the hassle and that the java libs should just be used directly
[15:14] <midnightmonster> I like them wrapped. Java APIs are ugly. I'd like them wrapped a bit better, though. helma.Http is pretty uninspired.
[15:17] <midnightmonster> "abstracting the implementation away from where it is used"--I think that's Java-think. YAGNI. If I write an improved version of helma.File, you can just replace helma.File with the better one. but odds are if I was improving something (like helma.Http) the big improvement would be in the interface. and then it wouldn't be drop-in anyway
[15:18] <zumbrunn> yes, but you could then control which implementation is used based on which reference you copy into your working scope...
[15:19] <zumbrunn> making the change for your entire app in one place, where you initialize the app
[15:20] <zumbrunn> like global.File = helma.myNewSupperDupperFileImplementation;
[15:21] <midnightmonster> I'm saying you're unlikely to need it, and if you did change libs it would more likely be for a more rational interface than for a different backend. but it doesn't matter. folks can do what they like in that regard.
[15:22] <midnightmonster> I do like having the wrappers, though, b/c without it it would have taken me a heck of a lot longer to get couchdb working. I don't come from JAva-land, and without at least working examples I wouldn't have known that connection.getContent() does something absolutely insane and I actually have to getInputStream() instead and feed that through some other StreamRelatedThing to get something usable.
[15:22] <zumbrunn> right now, the architecture we ended up with with the helma namespace and the way we include repositories is kind of a weird way of solving both the namespace and library/import problem in a mixed way
[15:23] <midnightmonster> I guess the way it does matter is if I did implement SuperFile that was backwards-compatible with File, I wouldn't easily be able to make the helma libs use
[15:23] <midnightmonster> it
[15:24] <zumbrunn> right, that's what i mean
[15:26] <zumbrunn> if we could define getters for undefined properties, we could hide all this behind a single Library object
[15:27] <zumbrunn> which would behave kind of like the Packages object
[15:27] <midnightmonster> you lost m
[15:27] <midnightmonster> e
[15:28] <zumbrunn> where Libraries.foo.Http could point to different implementations depending on how the getter is configured
[15:29] <midnightmonster> what keeps us from being able to do this?
[15:29] <zumbrunn> what keeps *me* from doing it is being able to define a getter method for undefined properties
[15:30] <zumbrunn> where Libraries.foo is undefined
[15:30] <zumbrunn> but the getter would resolve it to something dynamically
[15:32] <zumbrunn> then a Libraries object like this could also replace the current app.addRepository syntax
[15:33] <zumbrunn> at least for everything in certain pre defined locations like ./modules
[15:34] <midnightmonster> what do you need foo for if everything
[15:34] <midnightmonster> 's going to reference the canonical implmentation generically?
[15:35] <zumbrunn> Libraries.helma.Http would have to add/load that repository if it isn't loaded already
[15:35] <midnightmonster> e.g., shouldn't it just be Libraries.File that works magically? (and implementations stored in Libraries.ns.helma.File and Libraries.ns.muchBetterThanHelma.File)
[15:36] <zumbrunn> sure, could be
[15:36] <zumbrunn> but Libraries wouldn't have a File property
[15:36] <zumbrunn> not when you call it the first time, anyway
[15:37] <midnightmonster> right. but I took out foo. you can define a getter on Libraries 'cause it already xists
[15:37] <zumbrunn> so, I would need to be able to define a "default getter" on the Libraries object
[15:38] <zumbrunn> currently, you can define a getter for the File property, but not for a property of which you do not know the name in advance
[15:40] <midnightmonster> right, right. my bad.
[15:44] <midnightmonster> i think that's the single point on which PHP is more dynamic than JavaScript
[16:17] <midnightmonster> (only there's no easy way to set a getter for a *known* property name in PHP. you just get one getter function that has to handle them all)
[16:21] <zumbrunn> we always want to cookie and eat it too
[16:27] <midnightmonster> You can do this:
[16:27] <midnightmonster> myFile = new (Library('File'));
[16:27] <midnightmonster> but the xtra () makes it awkward and error-prone
[16:32] <zumbrunn> we could also do something like File = require('File');
[16:33] <zumbrunn> but then the difference to the app.addRepository('helma/File.js') syntax isn't big enough
[16:34] <zumbrunn> meaning, it's not a big enough improvement
[16:35] <zumbrunn> require('helma/File.js') was actually the syntax originally suggested by hannes back then
[16:36] <zumbrunn> we ended up going with app.addRepository instead mainly because back then app.addRepository didn't load the code immediately
[16:36] <zumbrunn> (the new code was not usable until the next request)
[16:38] <zumbrunn> which seemed to be specially confusing if it would have been named "require"
[16:42] <midnightmonster> indeed.
[16:43] <midnightmonster> I think require('File') might be a big enough improvement if it did all the fancy mapping stuff behind the scenes and mad it so my preferred File impl would be used by othr libs automatically
[16:44] <zumbrunn> maybe
[16:45] <midnightmonster> everyone would need to keep their own reference, though, b/c we don't want libs to put stuff in the global namespace
[16:49] <zumbrunn> I'm all for tabula rasa in the global scope, anyway
[16:49] <zumbrunn> http://helma.org/pipermail/helma-dev/2006-January/002581.html
[16:51] <midnightmonster> I so don't want to call helma.init to access res/req though
[16:51] <zumbrunn> well, that would be there already by default
[16:53] <midnightmonster> ?
[16:56] <zumbrunn> well, for example helma (or Libraries or whatever) could be the only non-core object that is "always" added to the global scope initially, but when an app starts up, it could invoke the default helma.init unless you define a custom init method
[16:56] <zumbrunn> helma.init would then copy the objects of the default helma framework into the global scope
[16:57] <zumbrunn> so, net result after a fresh blank app starts up would be the same
[16:58] <zumbrunn> with the difference that it would be easier to evolve the framework and do changes that break backwards compatibility
[16:58] <zumbrunn> because the compatibility would be freely configurable
[16:58] <zumbrunn> for example, by default, anything that is deprecated could be gone
[16:59] <zumbrunn> but you could easily include it if you want to run an app that still requires it
[17:02] <zumbrunn> I guess what I'm really saying is that helma should be two things at once:
[17:03] <zumbrunn> on one hand a very flexible core engine with which you can build any kind of server-side javascript environment you can dream off, like Rhino on Rails
[17:04] <zumbrunn> on the other hand, a framework that reflects the consensus of the "helma way" of building apps
[17:05] <zumbrunn> the result of the different experiments that is generally seen as the best approach
[17:05] <zumbrunn> a flexible core that comes with a default framework for coding by convention
[17:17] <midnightmonste2> ok. sounds reasonable. I was thinking I'd have to call helma.init very rquest
[17:20] <midnightmonste2> speaking of Rhino on rails, did you see Yegge's post that they're hoping to opensource it in 2008
[17:21] <zumbrunn> yeah, I saw you mentioned that here earlier
[17:21] <zumbrunn> or how mentioned that?
[17:21] <zumbrunn> who
[17:22] <zumbrunn> someone did
[17:22] <midnightmonste2> i did. but he also posted it on his blog since then
[17:23] <zumbrunn> I'm wondering how that architecturally will look like
[17:24] <zumbrunn> and how helma will be able to benefit from it, reuse it
[17:25] <zumbrunn> now it would be nice if we could wire HopObjects against the couchdb based backend
[17:26] <zumbrunn> using onInit and onPersist, but suppressing the built-in embedded db
[17:30] <midnightmonste2> I'm interested in how we could handle the caching
[17:32] <zumbrunn> if we use onInit and onPersist as the hooks to connect to couchdb, then Helma's built-in HopObjects will provide the caching.
[17:32] <midnightmonste2> but how will it know when it needs to update?
[17:33] <midnightmonste2> or I guess the built-in code will work so long as we don't change anything from outside helma
[17:33] <zumbrunn> you mean if the couchdb is changed from outside of helma?
[17:33] <zumbrunn> right
[17:34] <midnightmonste2> thing is, no analog of "collections" really exists in couchdb. it would be nice if helma did sql views, but it doesn't, and all there are in couchdb is views
[17:39] <midnightmonste2> the views are almost unlimitedly flexible--it would be very hard to support them in an automated way
[17:46] <zumbrunn> we could handle that using hobj.getChildElement(), no?
[17:51] <midnightmonste1> you'd have to, but the views can do all sorts of useful things... like return an entry and its comments all in one go
[17:58] <zumbrunn> so could hopobjects, then!
[18:32] <midnightmonste1> mailing list seems to be back
[18:32] <zumbrunn> yes, hannes is working on it
[18:33] <zumbrunn> your message didn't come through yet, though
[18:33] <midnightmonste1> it did to me
[18:33] <zumbrunn> just the bug
[18:33] <midnightmonste1> I got my user list message
[18:33] <zumbrunn> ok, it will probably come shortly
[18:34] <zumbrunn> yep, got it
[18:35] <midnightmonste1> oh--other thing: couchdb JSON can represent arbitrarily complex nested objects and arrays. hopobjects can't store those as they are... I'm not sure what we'd need to do to make that all work right
[18:40] <zumbrunn> hopobjects can have complex nested properties
[18:41] <zumbrunn> like you say, they by default just can't persist them
[18:43] <zumbrunn> but since we would use onInit and onPersist to leverage CouchDB for persistence, hopobjects would gain that capability
[18:54] <midnightmonste2> this would require hacking in the java code for hopobjects, right?
[18:55] <zumbrunn> to suppress the embedded db, yes
[18:55] <zumbrunn> and it might not be easy
[18:56] <zumbrunn> for example, since onInit happens "after" a object is fetched from the db
[18:58] <zumbrunn> (obviously)
[18:59] <midnightmonste2> you'd have to require a prototype property to indicate how the couchdb document should be instantiated. but I think that's ok--I like that idea anyway
[18:59] <midnightmonste2> (I'm not sure exactly what problem you're talking about wrt oninit, so I don't know if what I'm saying is related, just something I was thinking of)

 

 

In the channel now:

Logs by date: