Hopbot log for 2009-02-06 - Helma IRC channel: #helma on irc.freenode.net

2009-02-06:

[8:07] <mindlike> wanted you to take a look at something .. a while back i asked you how hard it would be to make helma bootstrap from a browser (applet?) rather than manual jar /server bootstrapping..
[8:07] <zumbrunn_> yeah, I remember that
[8:17] <decke> zumbrunn: good morning chris...
[8:18] <decke> found another strange bug... but i don't know if it's my fault or helma does something wrong in this case
[8:19] <decke> with an ASCII column in the mysql database there is an HopObject for it that uses that column as _name so it can be called as an URL and if someone types umlauts in it i get an mysql error
[8:19] <decke> java.sql.SQLException: Illegal mix of collations (ascii_general_ci,IMPLICIT) and (latin1_swedish_ci,COERCIBLE) for operation '='
[8:27] <zumbrunn> decke, maybe this helps? http://209.85.129.132/search?q=cache:OQexYTHetjQJ:www.knallgrau.at/company/weblog/files/helmabootcamp2_utf8/
[8:28] <zumbrunn> take a look at the last slide
[8:32] <decke> zumbrunn: that does not look promising... utf8 for colums that are only allowed to be ASCII or the hell breaks loose
[8:50] <mindlike> if this were done would helma be a portable, browser-based server.. similar to jnext but more of its true nature that being of a cms
[8:52] <mindlike> so the question is what stands in the way of starting helma in this mode
[8:53] <mindlike> but if it were done could you model new services not modelled in browsers without a remote server helping/relaying
[8:53] <mindlike> thereby losing the ability ot self-organize within the browser, without a central domain or server
[8:56] <zumbrunn> I can follow the argument that a way to web start a helma server could be interesting for some applications
[8:57] <zumbrunn> and that one would need an applet to do the web starting
[8:57] <zumbrunn> but I don't really see why helma would itself need to become part of that applet
[8:57] <zumbrunn> the applet would just be the installer, no?
[8:57] <mindlike> the applet is the hook only
[8:58] <mindlike> like the .bat or .sh
[8:58] <mindlike> you know more about java than me
[8:58] <mindlike> but sounds like you never use applets
[8:58] <mindlike> ?
[8:58] <zumbrunn> not so far
[8:59] <mindlike> because you do java only on server side right?
[8:59] <mindlike> the 'client-side' usages of java have largely been a joke.. minus processing
[8:59] <mindlike> weaknesses of the ui and html being a strong/easier to learn/disseminate/create with
[8:59] <mindlike> with flash following that up closely
[8:59] <mindlike> and java far far behind
[9:00] <mindlike> tho i know there's exceptions
[9:00] <mindlike> so its been artificially compartmentalized to the server ... largely because business and institutions found it most useful there
[9:01] <mindlike> the good news is the applet tag will always provide an important hook, that is if one wishes to endeavor to change the definition/rules for web application development
[9:01] <mindlike> game
[9:01] <mindlike> a few companies have been stealthily figuring this out
[9:02] <mindlike> for instance in my time doing flex development i've read of 'java helper programs' to do air-like things within the browser
[9:03] <zumbrunn> yes, an applet can pretty much be the hook for anything one would want to do
[9:03] <zumbrunn> as long as the user is willing to trust the applet
[9:04] <mindlike> well i think thats a classical concern but one people are most accustomed to doing
[9:04] <mindlike> with a signed applet
[9:04] <mindlike> versus the alternative for this invention which would be to use something like jnext
[9:05] <mindlike> but that would require using its extension api to write a custom plugin installer
[9:05] <mindlike> luckily the guy's already written an extension template for all browsers, but that to me is more sloppy than just trusting a java applet
[9:05] <mindlike> if you're made aware of the context of such trust
[9:05] <mindlike> like bitlet.org accomplished inbrowser
[9:05] <mindlike> or joost too.. in browser but with jetty running in stealth mode
[9:06] <mindlike> a couple years ago i saw a company doing this .. a torrent company actually
[9:06] <mindlike> kind like bitlet
[9:06] <mindlike> but i think it was a firefox only extension
[9:07] <mindlike> and akamai picked them up for about 10mill
[9:07] <mindlike> see akamai .. a company I used to develop for through nine systems, is affraid of anything that cuts into browser content delivery space
[9:07] <mindlike> and makes it cheap/efficient
[9:07] <mindlike> tho there's loss leaders now in the content delivery market, they're all pretty expensive
[9:07] <zumbrunn> so they baight it and shelft it?
[9:07] * zumbrunn bought
[9:08] <mindlike> no but i think they direct the dev now
[9:08] <mindlike> torrents are just a fact of life now
[9:08] <mindlike> but they have one disadvantage that akamai knows about
[9:08] <mindlike> they're not integrated with http / browser
[9:08] <mindlike> even bitlet, which is slowly making inroads on this, can't deliver content directly into dom
[9:08] <mindlike> realtime, but thats changing
[9:09] <mindlike> but the cable operators here in los angeles and u.s. are reacting interestingly
[9:09] <mindlike> instead of filtering torrents they're just putting large caps on things
[9:09] <zumbrunn> so, for which kind of app did you want to do this kind of webstart thing with helma?
[9:10] <mindlike> i think helma can be the portable overlay server
[9:10] <mindlike> and supernode servers would have a more complex / intricate startup order / stack
[9:10] <mindlike> but the portable node would be the basic helma config or maybe slightly hacked
[9:11] <mindlike> then you have say a flex video player
[9:11] <mindlike> on the client.. and helma in stealth.. talking to my helma in stealth which has the flv you need
[9:11] <mindlike> then you setup a topology /graph / flow routing table and share metric/availability data
[9:11] <mindlike> jk about last part, sorta
[9:12] <mindlike> basically you create a cloud out of thin-air (the clients)
[9:12] <mindlike> the context for such an event or trust to take place is open to debate tho
[9:13] <mindlike> for instance.. you know sproutbuilder?
[9:13] <zumbrunn> yes
[9:13] <mindlike> its basically a flex-built ide for building widgets
[9:13] <zumbrunn> well, *about* it only
[9:14] <mindlike> but one interesting thing you can do with it and its sdk/api is encapsulate widgets
[9:14] <mindlike> maybe i'm thinking of springwidgets too
[9:15] <zumbrunn> would the helma based nodes keep running after the applet starts them? or only while the user stays on that page?
[9:15] <mindlike> but in my time developing flex apps in past 6 months there's quite a bit of modular dev thats gone into making flex/actionscript interoperate.. and have the ability to embed/communicate/control your classes
[9:15] <mindlike> thats how sprout/spring work i think or through localinterface class of flash.mx
[9:15] <mindlike> preferance
[9:15] <mindlike> preference
[9:17] <mindlike> if you made it into a thing / layer of widget development.. like browser-to-browser/flash&hxhr-subverting udp/helma modules, etc
[9:17] <mindlike> thats why i was asking about the maturity of the torrent jala stuff
[9:19] <mindlike> because it seems fairly easy to just use something like vuze when they use many torrent fucntionality or url handling
[9:19] <mindlike> but use helma to organize the groups, do disk io, web server / cms (drupal-esque/integrated modularly)
[9:20] <mindlike> in my mind it'd be best to work with drupal and not alone
[9:20] <mindlike> along with java and flex.. the development communities are vast and somewhat independent of eachother
[9:20] <mindlike> you basically call it p2p for ajax/flex or cloud for ajax/flex
[9:21] <mindlike> or something else
[9:21] <mindlike> the business cases for it to me are unclear unless developers / consumers use/trust it
[9:22] <mindlike> once you have consumers doing what they want this this new power, and publishers/advertisers/creators vying for access to the space tho
[9:22] <mindlike> you self-organizing social networks that are fully autonomous potentially
[9:22] <mindlike> with no centralized infrastructure per se .. anyway food for thought
[9:23] <mindlike> maybe sci fi.. but i think its partly limited by whether i try to express/delineate/code up the prototype
[9:23] <mindlike> i keep seeing things scratch the surface of this idea.. some quite deeply but none quite want to change the game
[9:24] <mindlike> only serve their own interests/protocols/owners
[9:27] <mindlike> http://www.mindlike.com/CDN/
[9:28] <mindlike> anyways.. i'm out thanks for listen to my blather.. don't steal ;)
[9:28] <mindlike> it would take much from you to get my on my way.. and from my superficial reading / review of things.. i might be able to figure it out on my own
[9:36] <hannesw_> hi chris, you there?
[9:37] <zumbrunn> yes, just trying to think through our options reagrding modules again
[9:37] <hannesw_> what i don't understand - what is it that you lose by only supporting the exports object and dropping export()?
[9:37] <zumbrunn> for one thing, the ability to easily reuse code that wasn't written for that module style
[9:38] <zumbrunn> but, ok, I'm thinking about how valuable that really is
[9:38] <hannesw_> hm - why? you only add export.foo = foo for everything you want to export
[9:38] <hannesw_> and if we really want, we can implement an export() function to do just that...
[9:39] <zumbrunn> true
[9:39] <hannesw_> so the only real change is that it's the exports object to be used for require/import, and that's a real benefit imo
[9:39] <hannesw_> so basically i think it's a net win.
[9:39] <mindlike> s/would/wouldn't/
[9:40] <zumbrunn> yeah, just having to add export() probably would be ok
[9:40] <zumbrunn> so, we basically just flip the default
[9:40] <hannesw_> hm, yes, or: we make export() apply to require() and import(), in addition to include()
[9:41] <hannesw_> the only thing you have to watch is using this within an exported function, because it's going to apply to the exports object, not the module scope
[9:41] <zumbrunn> no you lost me
[9:41] <hannesw_> but that's ok imo - it's how included functions already work (this being the including scope)
[9:42] <hannesw_> well, if you use this within an exported function, and that function has been called with the exports object as this-object, then you won't see the non-exported members of the module
[9:42] <zumbrunn> by default, ng modules would work like the secure modules proposal
[9:43] <zumbrunn> except if export() is called without arguments, then we copy the module scope properties to the exports object
[9:43] <zumbrunn> is that what you meant, too?
[9:43] <hannesw_> noooo!
[9:43] <zumbrunn> oih
[9:43] <hannesw_> why would you do something like this? :-)
[9:43] <zumbrunn> lol :-)
[9:43] <hannesw_> i mean at least require something like export('*'), ok?
[9:43] <hannesw_> but i really think that's dangerous, and i like having a list of exported members
[9:43] <zumbrunn> ok :-)
[9:44] <hannesw_> that's why i prefer the export() function to the exports object actually
[9:44] <zumbrunn> yeah, but that's not how the proposal works
[9:44] <hannesw_> well i'm still considering whether the exports() function could be used in the securable modules proposal, but i see two problems:
[9:44] <hannesw_> it's a bit harder to implement,
[9:45] <hannesw_> export is reserved word in spidermonkey
[9:45] <hannesw_> plus there's a problem with evaluation order in strict mode 3.1, if i'm not mistaken
[9:46] <hannesw_> (in current js-engines, properties are defined before the script is evaluated, but i think es 3.1 strict mode wants to change this. but I'm not really sure)
[9:46] <hannesw_> sorry, gotta go...
[9:46] <zumbrunn> np
[9:47] <hannesw_> btw, i updated the gobi on dev.helma.org. the skins break a few minor features like the manage tab. i'm going to fix that later today.
[9:47] <zumbrunn> ok
[9:47] <hannesw_> i have a local copy where I'm fixing the skins.
[9:49] <hannesw_> zumbrunn: what would you think about going to a more stock gobi design on dev.helma.org?
[9:49] <hannesw_> (that would just make my job easier :-)
[9:49] <hannesw_> i think it's actually friendlier, with the blue title bar etc
[10:33] <zumbrunn> hannesw_: that *is* a bit friendlier, yes
[10:33] <zumbrunn> of course, it departs from the back and white you wanted to stick to
[10:34] <zumbrunn> actually, I would still suggest evolving the site design in the direction once suggested by knallgrau
[10:35] <zumbrunn> (the one Markus Schmeiduch designed)
[10:48] <zumbrunn> for example, if we would use something like the header and the content background from the reference pages, but with a toned down navigation bar on the right
[10:49] <zumbrunn> or we could try to come up with something that is still strictly back and white, but more elegant
[10:51] <zumbrunn> to evolve the site design, I could make some mockups of what we could do, if you like
[10:53] <zumbrunn> but if you prefer to go towards the default gobi look because it would make your life easier right now, I have no objection either, of course

 

 

In the channel now:

Logs by date: