Q & A with Marshall Culpepper

Introduction

This page documents our Q & A session with Marshall Cullpepper, one of the original developer's of Titanium Desktop during our scheduled Q & A session scheduled Friday June 15 at 3PM EDT / 1PM PDT on #tidesdk on freenode. The full range of discussion is below that provides valuable insights into the architecture and potential for TideSDK (as we look at the past, present and future).

This material will be consolidated in our developer orientation to fully acquaint new developers with our heritage. It will also offer clarity concerning the structure and architecture of the project, the type of issues involve in our development approach, library upgrades, distributing our software and more.

Topics

• Vision on TideSDK. Why this project should continue as a community effort?
• Architecture
  • Project structure explained
    • Tree structure
    • Slides
• Current Issues
  • Drillbit
  • Dependency bundles (Amazon S3 hosted)
• Distribution & Release Processes
• Remote Packaging
• Library Upgrade Path
  • Language upgrades
    • Python2 -> Python2.7/3
  • Upgrading webkit
  • Library upgrades
• Chrome Embedded
  • Mozilla XULRunner
• TiStudio/Aptana integration
• NodeJS
• Build and Test Processes
  • Continuous Integration
• Strategy for New Developers

The Session

• This was the QA session with Marshall Culpepper that was on June 15, 2012.

Preliminary chat

[13:21:30] <marshall_law> fairwinds: looks good for me now
[13:21:41] <marshall_law> ahh the link was missing an R somehow
[13:21:44] <marshall_law> Mashall
[13:21:45] <marshall_law> :)
[13:22:01] <blackorzar> jajajajaja 
[13:22:07] <blackorzar> sorry by that 
[13:22:15] <fairwinds> marshall_law:  had been updated but thing it threw link off
[13:22:23] <fairwinds> s/ think
[13:22:33] <fairwinds> heh
[13:22:46] <fairwinds> apologies in any case, has been fixed
[13:22:47] <marshall_law> fairwinds: hrm I'm not sure if I'll be able to provide the graphics..
[13:22:55] <marshall_law> I can definitely talk about architecture a bit though
[13:23:13] <wass3r> ascii graphics are acceptable :)
[13:23:22] <marshall_law> hehe :)
[13:23:26] <fairwinds> heh
[13:23:58] <blackorzar> jaja
[13:25:41] <fairwinds> marshall_law: np, we happy to have you here
[13:25:47] <marshall_law> fairwinds: I notice the 'kroll' submodule still points to Appcelerator (rather than the TideSDK fork)
[13:26:15] <marshall_law> fairwinds: you guys are going to need / want to fork https://github.com/appcelerator/webkit_titanium as well
[13:26:27] <marshall_law> maybe others
[13:26:28] <marshall_law> one sec
[13:26:59] <marshall_law> I *think* that should be all
[13:27:08] <fairwinds> k, I get this corrected
[13:27:12] <fairwinds> thx
[13:27:15] <marshall_law> np
[13:27:44] <fairwinds> blackorzar: you there?
[13:27:48] <blackorzar> sure
[13:28:01] <blackorzar> taking notes jaja
[13:28:50] <fairwinds> wonder if possible to get that graphic extracted from the slideshare on architecture then. Can you do that and put in wiki in 30mins?
[13:29:00] <blackorzar> sure
[13:29:13] <fairwinds> k, great, would be good for discussion for folks
[13:29:35] <fairwinds> boydlee: hi ya. welcome
[13:29:39] <boydlee> hey
[13:30:30] <fairwinds> many thanks for the things your company offering to help, this v awesome
[13:31:07] <fairwinds> am super excited about this kind of kickstart to bounties
[13:31:18] <marshall_law> oh man
[13:31:23] <marshall_law> you guys need to fix the build system :)
[13:31:35] <fairwinds> hahaha, you think
[13:31:40] <boydlee> I have a list of things in particular that all revolve around the Windows webkit implementation. It's currently the biggest problem and worst part.
[13:31:52] <boydlee> And a list of things to do with the build system particularly in Windows.
[13:32:08] <fairwinds> sure. I also have issues also too around this
[13:32:10] <marshall_law> sure
[13:32:10] <boydlee> But yeah the offer is considerable ... it's a considerable problem.
[13:32:18] <fairwinds> it is indeed
[13:32:28] <marshall_law> I can't guarantee I remember all the details, but I will definitely try my hardest :)
[13:33:31] <boydlee> What are you considering for the packaging process? Frankly I'd ditch any server-based packaging such as Appc used to run. I don't think it's necessary... getting a system setup for packaging is easy enough to be honest. It's just the scripts themselves and a few other things that need updating and fixing.
[13:33:46] <fairwinds> marshall_law: heh, I think the flow of discussion should be good. I think mostly we here to benefit from your insights and I think there will be a good number of quesitons.
[13:34:49] <fairwinds> boydlee: my complex apps in 50 - 150Mb range so understand where you coming from but for lighter apps I believe service has a place
[13:35:22] <fairwinds> I have embedded in there nodejs + an erlang key value store
[13:35:26] <boydlee> Maybe long term, but if the localized scripts are much improved first that would be a better place to begin
[13:36:35] <boydlee> but anyway.. webkit is the main thing I think. It really is terrible on Windows.
[13:36:43] <fairwinds> I think these don't have to be exclusive, if we have the ci for devs for our automated builds, we can take on packaging for light apps
[13:36:56] <fairwinds> for network packaging
[13:38:47] <fairwinds> I am a bit for status quo in short term so existing user not harmed in process
[13:39:06] <fairwinds> even though there has been a break
[13:39:15] <fairwinds> from discontinue
[13:39:32] <fairwinds> we see where it goes
[13:39:37] <fairwinds> collectively
[13:41:25] <fairwinds> well I guess we 20 mins away
[13:43:58] <blackorzar> Done: https://github.com/TideSDK/TideSDK/wiki/Architecture-Diagrams
[13:44:15] <marshall_law> have you guys been able to get webkit building in windows at all? it is definitely a difficult thing to do
[13:44:34] <marshall_law> I remember spending hours / days on it
[13:44:36] <boydlee> marshall_law: I have tried. Without succes.
[13:44:37] <blackorzar> some people have tried, but still othing
[13:44:50] <marshall_law> wish I had a windows VM around to test it, it might help jog my memory
[13:45:05] <blackorzar> cool :D
[13:45:06] <boydlee> Surely there's some leftover documentation around Appc somewhere on the basic process?
[13:45:10] <marshall_law> I may have one on my old external hard drive
[13:45:17] <marshall_law> boydlee: possibly, let me do some digging
[13:45:21] <boydlee> ta
[13:45:40] <fairwinds> blackorzar: nice
[13:45:45] <fairwinds> v good
[13:47:56] <fairwinds> marshall_law: graphics up on that link are pretty good
[13:48:09] <marshall_law> fairwinds: cool :)
[13:48:16] <marshall_law> forgot about those
[13:48:44] <fairwinds> it was a nice thing we found some days ago really
[13:48:53] <fairwinds> have been gathering things up
[13:49:11] <fairwinds> for orientation for devs and such
[13:50:03] <fairwinds> marshall_law: so this q&a also a part of what we wish to pass on
[13:50:21] <fairwinds> to aquaint folks
[13:53:10] <marshall_law> neat :)

Official Session

[14:00:28] <fairwinds> Great. so we 3:00 EDT
[14:00:48] <fairwinds> For those on channel wecome
[14:00:56] <marshall_law> hey guys :)
[14:01:19] <blackorzar> Cool :D
[14:01:21] <fairwinds> Am happy we have marshall culpepper for  a q& a on TiDesk
[14:01:58] <fairwinds> marshall was on of original developers and we are happy to have the benefit of his insights
[14:02:15] <fairwinds> We have put together a couple of aids for today
[14:02:28] <fairwinds> first the architectural diagrams:
[14:02:36] <fairwinds> https://github.com/TideSDK/TideSDK/wiki/Architecture-Diagrams
[14:02:56] <fairwinds> We also have the tree structure of the project
[14:03:48] <fairwinds> https://github.com/TideSDK/TideSDK/wiki/TideSDK-Project-Structure
[14:04:00] <wass3r> hi marshall and thanks for doing this :)
[14:04:12] <marshall_law> hi wass3r :)
[14:04:16] <fairwinds> We have assemble a bit of an outline to guide or Q &A
[14:04:36] <fairwinds> https://github.com/TideSDK/TideSDK/wiki/Q-&-A-with-Marshall-Culpepper
[14:05:07] <fairwinds> with that I think we can begin
[14:06:13] <fairwinds> can you tell us marshal a bit a bout how the project started and you vision at the time. and how you see this continuing in future
[14:06:25] <marshall_law> fairwinds: sure thing..
[14:07:52] <marshall_law> in the early days, Appcelerator was actually a Javascript framework for web application development. Jeff and Nolan (CEO/CTO respectfully) liked HTML5, but wanted to try and bring the native functionality of the desktop further to the web. We saw AIR and Gears at the time, and thought they were good first steps
[14:08:05] <marshall_law> but we wanted to go further, and do something open source that everyone could benefit from
[14:08:36] <marshall_law> so, they asked me to prototype and develop the first version of Titanium Desktop
[14:08:42] <fairwinds> awesome, so it was always your intent for project to remain fully open
[14:08:48] <marshall_law> yes :)
[14:09:13] <fairwinds> great, I let you contine
[14:09:16] <marshall_law> even the original "Appcelerator" project was open source, though not many people remember it now days (the project was renamed to Entourage, and I think might still be on github)
[14:09:41] <marshall_law> that's actually how kwhinnery got hired, he was a contributor / evangelist for the original Appcelerator project
[14:09:51] <marshall_law> anyway, enough of the history ;)
[14:09:56] <fairwinds> heh
[14:10:29] <fairwinds> On the basis of what you see currenlty, in what space do you see the future of tidesk
[14:10:33] <marshall_law> so the vision was always pretty straight forward: enable native functionality with web technolgoies
[14:10:36] <marshall_law> technologies *
[14:12:07] <fairwinds> we will have competition from other emerging technologies, do you see a foreseeable threat or opportunities to the project?
[14:12:08] <marshall_law> I still think there is a role for tide to play in the desktop app framework / platform space. AIR exists and is used by some, but there are still a lot of upstart open source wrappers around things like nodejs that try to accomplish the same thing, but burn out after realizing the complexity / enormity of the job :)
[14:13:17] <marshall_law> yeah, as HTML5 functionality closes the gaps, I think people will want to write those kind of apps instead
[14:13:38] <marshall_law> that isn't necessarily a problem, it just all depends on how you position the SDK moving forward I guess :)
[14:13:44] <fairwinds> we make much of kroll because it is something a bit special. There has been debate about the continuation of some of this language support , what is your opinion there
[14:14:32] <marshall_law> that's a great question
[14:14:35] <marshall_law> Kroll is kind of my baby
[14:14:59] <marshall_law> maybe the best architecture I ever was a part of
[14:15:05] <marshall_law> but..
[14:15:15] <marshall_law> that being said, I think there are a few problems with the approach.
[14:16:05] <marshall_law> one problem we ran into with a limited size team on TiDesktop was the complexity of maintaining the various language layers. each one adds an exponential amount of new things that need to be tested
[14:16:26] <marshall_law> if I had to do it over again, I would probably pare down the language layers
[14:16:42] <marshall_law> not to say tide shouldn't support multiple languages
[14:16:53] <marshall_law> but, you should probably choose the ones you want carefully, and sparingly
[14:16:53] <fairwinds> yes, actually on leadership meetings suggested that only python remain
[14:17:02] <marshall_law> yeah, I don't disagree with that
[14:17:05] <fairwinds> is what I recommended
[14:17:14] <wass3r> +1
[14:17:33] <marshall_law> ruby is also a strong community / contender, but I don't want to start a language holy war :)
[14:17:42] <fairwinds> hehe I understand
[14:17:54] <fairwinds> python is super glue almost everywhre
[14:18:13] <fairwinds> and with rich and stable libs
[14:18:20] <marshall_law> yup, agreed
[14:19:02] <wass3r> that might be good especially to start with.. i can see the issues with maintaining the multitude of languages with a small group
[14:19:43] <marshall_law> Kroll was really designed for cross-language binding in mind. it is essentially "dynamic" in nature -- querying and exposing objects at runtime rather than having static / generated bindings like other binding layers do (i.e. SWIG)
[14:20:12] <marshall_law> there are trade offs to each approach
[14:20:26] <fairwinds> yes, that is what I like about it myself
[14:20:32] <marshall_law> a dynamic binding layer has the advantage of smaller binary size, and more flexibility
[14:20:49] <marshall_law> a static binding layer gives you better runtime speed
[14:21:32] <marshall_law> since tide is a desktop SDK, I consciously made the decision for the former rather than the latter
[14:22:00] <marshall_law> for comparison, Titanium Mobile (for Android at least) uses a static binding model
[14:22:24] <marshall_law> it costs more in binary size, but offers an improved runtime footprint, which is much more important on mobile devices
[14:22:46] <fairwinds> marshall what do you think about incorporating kroll directly into ti desk as opposed to maintaining separate project for kroll. I tend to want to keep them so kroll may have other opportunities on its own in future but I really don't like submodules that much in git
[14:23:27] <marshall_law> fairwinds: that was always our intention as well -- Kroll could theoretically be the binding layer / microkernel for other projects :) It never worked out that way in practice, but is something I'd always hoped for it
[14:23:47] <fairwinds> I am not sure what sort of uptake there has been on kroll but I have my own ideas :-)
[14:23:58] <marshall_law> fairwinds: submodules are a pain, have you tried google's "repo" ? a nice alternative (we use it in boot2gecko actually)
[14:24:26] <fairwinds> yeah, have tried repo with couchbase.
[14:24:52] <fairwinds> for builds off mobile couchbase, it was alright
[14:25:02] <marshall_law> :)
[14:25:14] <fairwinds> s/ of
[14:25:18] <marshall_law> it makes branch / submodule management much more intuitive IMO, but I digress
[14:25:27] <fairwinds> sure
[14:25:36] <fairwinds> I think we should move on to architecture
[14:25:40] <marshall_law> sure
[14:25:48] <fairwinds> since we have some topics to get through
[14:26:25] <fairwinds> I think a general description of the project sturcture and key folders is helpful for new devs
[14:26:56] <fairwinds> can you describe this for folks based on the structure I have provided
[14:27:10] <fairwinds> https://github.com/TideSDK/TideSDK/wiki/TideSDK-Project-Structure
[14:27:26] <marshall_law> sure thing
[14:28:45] <marshall_law> so "kroll" obviously is the reference to the kroll project -- many of the core components of tide live here, such as the stub "network" installer, the Kroll binding layer, the Kroll module loader system, and a host of utility classes/functions that are used by Titanium and the installers
[14:29:19] <marshall_law> the majority of the kroll specific code is in kroll/libkroll
[14:29:47] <marshall_law> "kroll" also contains the command line scripts for Titanium
[14:30:02] <marshall_law> at least, the majority of the code
[14:30:03] <marshall_law> :)
[14:30:06] <marshall_law> see kroll/tools
[14:30:25] <marshall_law> the SCons build system and Titanium command line scripts both depend on those scripts
[14:31:18] <marshall_law> and finally, the language-specific support implementations also live under kroll/modules/$language
[14:31:38] <marshall_law> back up to the top level tide..
[14:32:11] <marshall_law> each subfolder under "modules" describes a kroll module that is part of the tide API
[14:32:58] <fairwinds> marshall, while in the kroll module, can you speak of the nature of the third party libs, what you were doing to build/bundle dependencies and host on amazon s3.
[14:33:22] <wass3r> thanks for joining sh3bby, marshall is walking us through https://github.com/TideSDK/TideSDK/wiki/TideSDK-Project-Structure at the moment.. agenda is here for the Q&A: https://github.com/TideSDK/TideSDK/wiki/Q-&-A-with-Marshall-Culpepper
[14:33:24] <marshall_law> generally, modules in kroll/tide live on the top level object ("Titanium.Module"), and have an extension of kroll::Module, with an Initialize() entry point function
[14:33:57] <marshall_law> fairwinds: sure thing
[14:34:11] <sh3bby> wass3r: Cheers!
[14:34:26] <fairwinds> please continue did not want to interrupt  your flow
[14:34:41] <marshall_law> :) no worries just refreshing my memory a bit as I go :)
[14:35:10] <fairwinds> :-)
[14:35:22] <marshall_law> so the structure of the thirdparty directory is pretty straight forward..
[14:35:47] <marshall_law> the thirdparty tarball is there to provide pre-built dependencies for titanium
[14:36:15] <marshall_law> the majority of the dependencies are vanilla (growl, php, poco)
[14:36:48] <marshall_law> in other words, you can grab a recent release source tarball of those projects, build them, and package the necessary files in include/lib
[14:37:06] <marshall_law> each dependency has it's own folder under the thirdparty folder/tarball
[14:37:33] <marshall_law> and under each of those thirdparty folders, generally lives an "include" that gets automatically put in -I for compilation, and a "lib" that gets distributed with tide sdk
[14:38:03] <marshall_law> for OS X, dylib live under lib, for Linux, .so, for win32, .dll
[14:38:33] <marshall_law> webkit also bundles frameworks instead of lib or include for OS X
[14:38:55] <marshall_law> if you browse through our build script code, you can see that we just build against those frameworks
[14:39:01] <marshall_law> (for OS X)
[14:39:26] <marshall_law> in terms of how the thirdparty bundles are managed
[14:40:19] <marshall_law> our usual workflow was to cp -r thirdparty-$OS-$ARCH-$REVISION thirdparty-$OS-$ARCH-$REVISION+1
[14:40:39] <marshall_law> then copy the newly built binaries / headers into the $REVISION+1 folder to override the old binaries/headers
[14:40:53] <marshall_law> (for whichever specific thirdparty bundle we're updating)
[14:41:01] <marshall_law> then tar up the directory
[14:41:12] <marshall_law> cd thirdparty-$OS-$ARCH-$REVISION+1
[14:42:12] <fairwinds> super this is very helpful insight
[14:42:57] <marshall_law> tar cf ../thirdparty-$OS-$ARCH-$REVISION+1.tar .
[14:43:03] <marshall_law> cd ..
[14:43:10] <marshall_law> gzip thirdparty-$OS-$ARCH-$REVISION+1.tar
[14:43:13] <marshall_law> :)
[14:43:40] <marshall_law> there is also a revision number tracked in kroll/SConscript.thirdparty for each platform/arch combo
[14:43:51] <marshall_law> so you simply need to bump that version
[14:44:00] <fairwinds> yup
[14:44:08] <marshall_law> and upload your tarball to S3
[14:44:27] <fairwinds> sure
[14:44:52] <marshall_law> the naming / URL schemes for all that are pretty straight forwardly coded in the SConscript.thirdparty near the top :)
[14:45:50] <marshall_law> any more questions about thirdparty distribution?
[14:46:03] <blackorzar> pure gold :D
[14:46:06] <marshall_law> :)
[14:46:16] <fairwinds> blackorzar: you are a happy man
[14:46:18] <marshall_law> we tried to keep it as simple as possible :)
[14:46:23] <cb1kenobi> sup all
[14:46:44] <marshall_law> cb1kenobi: hey stranger :)
[14:46:48] <blackorzar> fairwinds: you don't have an idea! 
[14:46:56] <fairwinds> heh
[14:47:10] <blackorzar> hi cb1kenobi
[14:47:23] <marshall_law> so back to the project structure
[14:47:28] <fairwinds> cb1kenobi: sure
[14:47:45] <fairwinds> marshall_law: super
[14:47:59] <marshall_law> under tide, the sdk directory contains the main packaging script (tibuild.py) and it's dependencies
[14:48:23] <marshall_law> those other scripts (app.py, etc) are actually really nice python APIs for packaging a titanium app
[14:48:30] <fairwinds> cb1kenobi: marshall is walking us through https://github.com/TideSDK/TideSDK/wiki/TideSDK-Project-Structure at the moment.. agenda is here for the Q&A: https://github.com/TideSDK/TideSDK/wiki/Q-&-A-with-Marshall-Culpepper
[14:48:48] <marshall_law> tibuild.py is fairly baron / a wrapper around those others :)
[14:49:01] <cb1kenobi> fairwinds: sweet, thanks for the info
[14:49:53] <marshall_law> the "installer" directory contains the graphical installer implementation for each platform. this is the application specific installer (for end users)
[14:50:27] <marshall_law> much of this code is templated to work against a specific titanium application, but some of it is pre-built during the SDK compilation as well
[14:51:04] <fairwinds> marshal_law: I have been doing windows builds for my erlang projects, do you have a favorite installer there?
[14:51:37] <fairwinds> for windows and would you reommend any change
[14:51:57] <marshall_law> I will apologize up front for whoever has to maintain the windows installer :)
[14:52:02] <wass3r> lol
[14:52:03] <fairwinds> hehe
[14:52:22] <fairwinds> I have been using inno5 myself
[14:52:25] <fairwinds> for windows
[14:52:30] <marshall_law> fairwinds: there aren't any good ones, IMO
[14:52:36] <fairwinds> heh
[14:52:51] <marshall_law> some people like izpack, which isn't terrible I guess
[14:53:06] <fairwinds> but also nsis used in by ericsson on erlang so stuck with that there
[14:53:15] <marshall_law> our original implementation was based on WIX, but IIRC that got gutted
[14:53:23] <fairwinds> ic
[14:53:30] <fairwinds> I see
[14:53:33] <marshall_law> MSI is fairly problematic
[14:54:06] <marshall_law> NSIS isn't really maintained IIRC, but it is pretty stable
[14:54:24] <fairwinds> it is a very slow moving thing
[14:54:37] <fairwinds> 2.46u is where I am at on that one
[14:54:43] <marshall_law> fairwinds: I've never tried inno5 to be honest, if you find it useful and intuitive, I say go for it. the windows installer was a constant pain in our side :)
[14:55:00] <fairwinds> k, sure
[14:55:13] <fairwinds> is not so bad from my view
[14:55:32] <marshall_law> the non-WIX MSI based installer is definitely easier to understand
[14:56:32] <marshall_law> "site_scons" is a special SCons folder -- any script inside that directory gets preloaded by SCons and can be used for dependencies or other misc build necessities
[14:57:49] <marshall_law> finally, the "tools" folder is where tide based apps that are a part of the SDK live
[14:58:21] <marshall_law> drillbit is the custom unit test suite written for tide  (on top of tide)
[14:59:04] <marshall_law> you can see a full list of the unit tests under drillbit/Resources/tests
[14:59:28] <marshall_law> drillbit actually has it's own unit test API
[14:59:41] <marshall_law> just take a look at any one of the many unit tests there and you can get a feel for it
[15:00:48] <marshall_law> "sandbox" is a simple boilerplate app that lets you put any test code you want in the sandbox/Resources/index.html
[15:01:01] <marshall_law> oh btw all of these apps can be built / run directly with "scons <app>"
[15:01:14] <marshall_law> or maybe scons <app>=1 :) now i need to remember
[15:01:28] <fairwinds> heh
[15:01:37] <marshall_law> it's one of the two :)
[15:01:40] <fairwinds> this are very good explantions
[15:02:03] <fairwinds> explanations even :-)
[15:02:12] <marshall_law> hehe
[15:02:41] <marshall_law> "sdkinstaller" is the installer for the SDK itself -- this is also basically an empty app that has the sole purpose of declaring a dependency on the SDK, which makes kroll invoke it's netinstaller
[15:03:18] <marshall_law> it takes advantage of the fact that kroll has a built in netinstaller to resolve dependencies
[15:03:59] <marshall_law> so the installer for the SDK... is an app built on the SDK :)
[15:04:15] <fairwinds> cool
[15:04:38] <fairwinds> btw, how were you using the sandbox app specifically?
[15:04:38] <Matt__> Hello again
[15:04:44] <marshall_law> I missed "apidocs" -- this is the user facing API documentation in YAML format
[15:05:09] <marshall_law> there is a script that collects and formats the docs called apidoc/docgen.py
[15:05:18] <marshall_law> which uses the apidoc/templates
[15:05:30] <marshall_law> "apidocs" -> "apidoc"
[15:05:54] <marshall_law> fairwinds: sandbox is useful for debugging specific problems during development of the SDK itself
[15:06:01] <fairwinds> yes. I am currently doing some things here to script in py to generate markdown that gets dumped to a sphinx
[15:06:05] <marshall_law> you can copy paste in problematic code and debug it
[15:06:22] <marshall_law> neat
[15:06:57] <fairwinds> we then build our multi-lang docs then throough read-the-docs
[15:07:10] <marshall_law> IIRC, scons will build the SDK in debug mode by default, so you can go directly to the web inspector (or attach a native debugger like gdb)
[15:07:17] <Matt__>  fairwinds: got a video card. rebuilding now
[15:07:55] <marshall_law> the only other relevant project that needs to be explained is webkit_titanium
[15:07:57] <fairwinds> Matt__:  cool. marshall is walking us through https://github.com/TideSDK/TideSDK/wiki/TideSDK-Project-Structure at the moment.. agenda is here for the Q&A: https://github.com/TideSDK/TideSDK/wiki/Q-&-A-with-Marshall-Culpepper
[15:07:59] <marshall_law> AFAIK
[15:08:18] <marshall_law> fairwinds: have you forked webkit_titanium yet?
[15:08:31] <marshall_law> not a big deal if not, I can just link the appcelerator repo
[15:08:37] <fairwinds> no not yet,
[15:08:57] <fairwinds> I can do, give me sec
[15:09:04] <marshall_law> http://github.com/appcelerator/webkit_titanium
[15:09:06] <marshall_law> n/p
[15:09:22] <marshall_law> so this is essentially the tide sdk fork of webkit
[15:09:46] <marshall_law> as far as I know, we didn't add any new folders or anything.. it is a pretty standard source distribution of webkit
[15:09:57] <marshall_law> the only major differences are our source patches
[15:10:07] <fairwinds> https://github.com/TideSDK/webkit_titanium
[15:10:13] <marshall_law> fairwinds: sweet!
[15:10:35] <marshall_law> one thing you might notice off the bat is the age of the repo.. no commits in a year :) someone will probably want to update to the latest
[15:10:44] <fairwinds> sure
[15:10:52] <marshall_law> webkit has their own git repo that this was forked from, IIRC
[15:11:10] <marshall_law> yeah https://github.com/webkit/webkit
[15:11:24] <marshall_law> might be better to fork that, and re-apply our patches :)
[15:11:29] <fairwinds> k, this good to keep in mind
[15:11:45] <fairwinds> sure
[15:12:16] <Matt__> marshall_law: Was the webkit update and apply-patch process automated?
[15:12:20] <wass3r> marshall_law: and that was always an issue too right? keeping webkit updated?
[15:12:33] <marshall_law> Matt__: nope, we did it by hand
[15:12:46] <marshall_law> wass3r: yeah, it can be problematic. Webkit moves fast
[15:12:53] <fairwinds> https://github.com/TideSDK/webkit
[15:13:03] <Matt__> marshall_law: Were there often issues?
[15:13:11] <marshall_law> one thing we did was to try and use stable tags if at all possible
[15:13:44] <blackorzar> BigMacAttack: marshall is walking us through https://github.com/TideSDK/TideSDK/wiki/TideSDK-Project-Structure at the moment.. agenda is here for the Q&A: https://github.com/TideSDK/TideSDK/wiki/Q-&-A-with-Marshall-Culpepper
[15:13:49] <marshall_law> Matt__: sometimes yes, sometimes no. it looks like the majority of our patches have been collected into one or two commits from Josh now, so hopefully the changeset is small and relatively easy to correct
[15:15:12] <marshall_law> hrm maybe not
[15:15:42] <marshall_law> Matt__: fairwinds: you guys should probably go through the git log on webkit_titanium and find commits by Josh, it will give you an idea of what's been changed (you can skip the "merge upstream" commits)
[15:15:59] <Matt__> Ok, thanks
[15:16:03] <fairwinds> super
[15:16:11] <marshall_law> IIRC the changeset wasn't huge though
[15:16:26] <fairwinds> that make a bit of relief actually
[15:16:27] <marshall_law> mostly it was for adding support for non-Javascript languages in the <script> tag?
[15:16:35] <marshall_law> there may be others I'm forgetting
[15:16:36] <fairwinds> k
[15:17:20] <marshall_law> probably the biggest pain in webkit was building in windows, which you guys have alluded to :)
[15:17:45] <marshall_law> I searched all around for documentation but I couldn't find any unfortunately
[15:17:58] <fairwinds> I will give a go. I am tenacious
[15:18:07] <marshall_law> I'm assuming you guys have already tried http://trac.webkit.org/wiki/BuildingCairoOnWindows?
[15:18:14] <marshall_law> FWIW we use the windows cairo release
[15:18:19] <blackorzar> we identified it
[15:18:23] <blackorzar> :)
[15:18:27] <blackorzar> still not tried
[15:18:30] <marshall_law> kk
[15:19:05] <marshall_law> wow, I'm amazed they still only support Visual Studio 2005 :)
[15:19:11] <marshall_law> 7 year old software
[15:19:22] <fairwinds> yes I a building on 2010 as defacto
[15:19:28] <fairwinds> am
[15:19:47] <fairwinds> for projects
[15:19:48] <marshall_law> that was one major problem..
[15:19:57] <marshall_law> the Cairo port on windows wasn't really "owned"
[15:20:07] <marshall_law> by anyone other than us, and Brent Fulgham
[15:20:25] <marshall_law> I'm not sure if Brent is still actively trying to build in win32/cairo
[15:20:46] <marshall_law> he's bfulgham in #webkit
[15:20:48] <fairwinds> we should likely track him down
[15:20:53] <fairwinds> right
[15:21:01] <fairwinds> we on same waves
[15:21:35] <fairwinds> and likely pass some other details we may need on the build
[15:21:47] <marshall_law> yeah, I'm sure he will be able to help more with that
[15:22:03] <marshall_law> k, next? :)
[15:22:53] <fairwinds> I think we want some insight on distribution and release processes
[15:23:05] <fairwinds> next
[15:23:06] <marshall_law> sure
[15:23:53] <marshall_law> so Kroll has the concept of a "component"
[15:24:31] <marshall_law> components are essentially versioned artifacts that either live in the system's Titanium SDK folder, or can be downloaded and installed/extracted to the SDK folder
[15:25:25] <marshall_law> the types of components are basically:
[15:25:27] <marshall_law> SDK (the fully-bundled SDK with all modules, and dependencies)
[15:25:50] <marshall_law> "runtime" (the base titanium runtime+dependencies)
[15:26:31] <marshall_law> and each module in kroll/modules and tide/modules are a component
[15:27:23] <marshall_law> if you have Titanium desktop installed on a Mac, you might see /Library/Titanium/sdk /Library/Titanium/modules .. etc
[15:27:35] <marshall_law> there are subfolders pertaining to each component, and it's version
[15:28:14] <marshall_law> there is an "sdk" target of scons that will build and package up all the necessary zips for each of these components
[15:28:52] <marshall_law> right now, when Kroll tries to run a tide application on a machine, it looks at the "manifest" file to find out the components that the app depends on
[15:29:08] <marshall_law> Kroll will then try to resolve those dependencies in the system Titanium folder
[15:29:36] <marshall_law> if a dependency can't be resolved, the netinstaller will be opened to automatically fetch that component
[15:29:54] <marshall_law> right now Kroll has the appcelerator URLs for components built in
[15:30:01] <marshall_law> but that can be pretty easily changed
[15:31:02] <marshall_law> at Appcelerator, we actually had a proprietary web service that we developed that allowed us to upload these SDK zips, and would automatically give JSON indexes etc for them
[15:31:40] <marshall_law> right now I think the Kroll layer depends on the JSON responses from the appcelerator web services, and should probably be changed to whatever backend you guys decide to use
[15:32:02] <marshall_law> the main challenge for TideSDK will be how to replace the appcelerator web services...
[15:32:12] <fairwinds> yes, for sure
[15:32:22] <fairwinds> this is on our minds
[15:32:36] <fairwinds> have you any recommendations here
[15:32:55] <marshall_law> honestly, the web service that we have there was pretty crude. a dedicated person or 2 could probably write an alternative in a week or so :)
[15:33:10] <wass3r> use nodejs
[15:33:15] <wass3r> :D
[15:33:16] <fairwinds> exactly
[15:33:45] <marshall_law> the main purpose is to take zip files, put them in S3, and give a web api for querying them
[15:33:59] <fairwinds> is more a matter at this point of knowing what it did
[15:34:00] <marshall_law> a lot of that is provided by s3 directly, to be honest
[15:34:13] <fairwinds> sure
[15:34:38] <marshall_law> the main utility the web API had was the packaging service
[15:35:06] <marshall_law> the packagers would bootstrap from the components that the web API managed
[15:35:13] <fairwinds> and those just use same packaging scripts we already know
[15:35:22] <fairwinds> from the sdk
[15:35:23] <marshall_law> yup
[15:35:30] <fairwinds> k
[15:35:40] <marshall_law> also there is an update service that titanium apps will ping periodically
[15:35:50] <marshall_law> basically "tell me the latest version of component X"
[15:36:10] <marshall_law> for apps, newer versions mean (possibly) prompt the user to install the latest version
[15:36:35] <marshall_law> when we used titanium developer, a newer version of the SDK meant the SDK got updated through titanium developer :)
[15:37:15] <fairwinds> I am not certain yet how we will coordinate with tiStudio yet but plan is to coordinate SDK update  if there is cooperation with Appc. tiStudio is not our product so need there coordination to continue
[15:37:30] <marshall_law> this whole system was pretty haphazardly put together though (I remember the late nights too well), honestly breaking free of appcelerator and engineering an open solution is probably in everybody's best interest
[15:37:56] <fairwinds> sure
[15:38:09] <marshall_law> fairwinds: I would say do whatever you guys have to do first, TiStudio integration would be nice but it is not a killer feature for you IMO
[15:38:23] <marshall_law> probably better to earn your own identity and community
[15:38:50] <fairwinds> sure
[15:39:05] <marshall_law> I would say SDK updates can be handled through the standard developer channels -- i.e package managers
[15:39:16] <marshall_law> (just thinking out loud)
[15:39:29] <fairwinds> yup, understand
[15:58:49] <fairwinds> I think we in talk now about to begin topic for lib upgrade process
[15:59:04] <fairwinds> blackorzar: is that you take also
[15:59:11] <fairwinds> your
[16:00:05] <marshall_law> hehe
[16:00:08] <marshall_law> yeah I'm good
[16:00:13] <fairwinds> awesome
[16:00:13] <blackorzar> cool :)
[16:00:29] <fairwinds> blackorzar: nice job on posting
[16:01:12] <marshall_law> so for some environments/languages, the language runtime is included with the language support
[16:01:38] <marshall_law> right now IIRC php 5.3 is bundled in all environments, python and ruby are bundled for windows only
[16:01:53] <marshall_law> it's assumed you have python/ruby installed on a linux or osx machine
[16:02:19] <meeech> fairwinds: yeah, i have log as well if it turns out you guys need it
[16:02:25] <fairwinds> k, super
[16:02:32] <marshall_law> that is another reason I would recommend paring down language support -- updating a binary runtime distribution is a PITA, especially with different architectures, OS versions, etc... too much IMO
[16:03:10] <fairwinds> right. I have strong feelings after discussion about a pare down for sure
[16:04:00] <marshall_law> generally, for updating to a new version of  a language, just the build system targets need to change (if at all). for the languages that get bundled, you will need to take a look at the existing thirdparty bundle for that platform and see how the structure is different from the official language distribution. I don't think it's terribly different -- maybe just some pruning
[16:05:03] <marshall_law> this is probably only really relevant for windows -- where python 2.5 (!) is still bundled
[16:05:12] <fairwinds> sure. on python, we hitting a point of a 2.7 / 3.2 but obviously stay in step with system py
[16:05:25] <fairwinds> heh
[16:05:25] <marshall_law> yeah I would highly recommend 2.7
[16:05:34] <marshall_law> I don't have much experience 3.2
[16:05:38] <marshall_law> so :)
[16:05:42] <fairwinds> yes this is goal
[16:06:16] <fairwinds> 3.x a bit off for systems into future
[16:06:38] <fairwinds> but coming soon, more and more ported all the time
[16:08:21] <fairwinds> we allready spoke on the upgrading of webkit, the other dependency libs may also need upgrades
[16:08:52] <fairwinds> anything here that may pose a challenge this way from your perspective?
[16:10:23] <fairwinds> One of the most important first efforst we will make as a team is to bring the libs up to date
[16:11:25] <fairwinds> Certainly updated webkit wlll breathe some new life
[16:12:57] <fairwinds> marshall_law: we may have lost you temporarily
[16:13:00] <marshall_law> sorry
[16:13:02] <fairwinds> np
[16:13:03] <marshall_law> starting to get pinged
[16:13:05] <marshall_law> :)
[16:13:07] <fairwinds> heh
[16:13:28] <marshall_law> the only other lib I can think of in terms of importance is Poco
[16:13:41] <marshall_law> this is a system C++ library that Kroll and Titanium depend on for a number of things
[16:14:21] <marshall_law> IIRC the process was pretty straight forward.. you can build the vanilla libs and includes and copy them into the thirdparty folder
[16:14:31] <fairwinds> do you see any obvious barriers to working with recent libs?
[16:14:38] <fairwinds> most recent
[16:15:18] <marshall_law> the only thing I can think of would be potential use of deprecated APIs by Titanium. it's definitely a possibility given the age of the project, but I'm not sure to be honest
[16:15:49] <fairwinds> k, sure. we likely be hitting this and will work through it
[16:16:33] <fairwinds> I believe we now to possible use of Chrome Embedded
[16:17:23] <fairwinds> and whether we ought to look strongly here as there has been considerable pointing in this direction
[16:17:33] <fairwinds> for the future
[16:18:00] <marshall_law> ooh
[16:18:03] <marshall_law> yeah, I like that idea :)
[16:18:08] <fairwinds> What is your opinion of this integration
[16:18:30] <marshall_law> I think it's a great idea -- it would remove a lot of the problem of custom binary distribution
[16:18:57] <marshall_law> FWIW, Titanium desktop's version 0.1 was actually based on Chrome in windows
[16:19:24] <marshall_law> that was before even Kroll though :) it was pretty crude
[16:19:31] <fairwinds> wow. how would you tackle such a major change if you were leading this project today?
[16:19:53] <marshall_law> honestly? I would probably start from scratch
[16:20:06] <fairwinds> heh
[16:20:07] <marshall_law> and come back to find code that can be reused in the new system
[16:20:21] <fairwinds> I see. So start a new repo
[16:20:24] <fairwinds> and build up
[16:20:27] <marshall_law> yeah, it wouldn't be a bad idea
[16:20:47] <marshall_law> Chromium has it's own C++ binding APIs that are pretty Javascript specific
[16:21:04] <marshall_law> actually parts of the Kroll binding layer were inspired by the chromium binding layer circa 2008
[16:21:30] <fairwinds> cool
[16:21:34] <marshall_law> I think there is still some chromium code in the callback binding part
[16:22:45] <fairwinds> we will have limited human capacity on the project for a while and this is one challenge so important to determine our path
[16:23:27] <fairwinds> Josh has done some work on embedded chromium but have not seen it yet
[16:23:49] <marshall_law> ah yeah
[16:23:54] <marshall_law> that's cool
[16:24:00] <fairwinds> was hoping he might be here today to talk about any progress there
[16:24:33] <marshall_law> I think either chrome embedded or xulrunner are good options. XULRunner is a little older, might give you more problems (though admittedly I haven't played with it in a long time)
[16:25:08] <marshall_law> I guess the other potential direction is to bootstrap on top of nodejs ? :)
[16:25:26] <fairwinds> I have played with XULRunner a bit myself and yes is old and not so well
[16:25:57] <marshall_law> the main technical hurdle with using nodejs would be integrating the nodejs v8 with your rendering engine (presumably chromium?)
[16:26:36] <marshall_law> it would be a fun (but probably not terribly easy) project to make nodejs build / bootstrap into an existing v8 vm
[16:26:55] <fairwinds> right. currently I am able to use nodejs embedded  and boostrap with python to control process
[16:26:58] <marshall_law> i.e. bootstrap nodejs into the DOM :)
[16:27:26] <marshall_law> embedded into chromium?
[16:27:53] <fairwinds> no, into a tiDesktop app. binaries are bundled into the app
[16:29:13] <fairwinds> when app starts in the javascript there is call to python to launch server basically
[16:29:23] <wass3r> i have to run.. i will follow up with the transcript.. thanks again for doing this marshall!
[16:29:34] <fairwinds> wass3r: cu
[16:30:13] <fairwinds> so I am lauching a couple of processes, to run nodejs server and also a erlang vm
[16:30:22] <fairwinds> within the app
[16:30:39] <marshall_law> ahh interesting
[16:30:50] <marshall_law> yeah, that's pretty expensive too though :)_
[16:30:59] <fairwinds> it is uhu
[16:31:15] <fairwinds> but works but is a heavy solution
[16:31:34] <marshall_law> IMO the best bet is probably to start with chromium embedded, and gut the parts of node.js (like commonjs) that you need. you should be able to bootstrap node.js modules theoretically, since chromium also uses V8
[16:32:15] <fairwinds> yup
[16:32:44] <marshall_law> nodejs has a really bad problem for desktop / app distribution
[16:32:48] <marshall_law> ABI compatibility
[16:33:05] <marshall_law> I think they are trying to solve this now with a C API for modules
[16:33:12] <marshall_law> not sure though
[16:33:35] <fairwinds> It was a challenge for node to be running on Windows actually
[16:33:51] <marshall_law> anyway, if a specific module gets updated and built against a newer V8, the possibility of that compiled module working against an earlier version of node is low
[16:34:22] <fairwinds> sure. btw are you familiar with apple's new requirements for Sandboxing apps
[16:34:38] <marshall_law> nodejs works well as a server because generally the entire environment is setup to build from source rather than have prebuilt binaries distributed
[16:34:48] <marshall_law> once you start distributing binaries, everything gets hairy
[16:34:49] <fairwinds> right
[16:35:41] <marshall_law> I'm aware they exist, but I'm not familiar with the specifics :)
[16:36:14] <fairwinds> The gist is that apple does not want the app running in the wild west
[16:36:26] <fairwinds> for security
[16:37:23] <fairwinds> I am thinking we have some upgrades and basic work first but this will be our next most important priority
[16:37:39] <fairwinds> to retain app store capability
[16:37:56] <fairwinds>  or we loose if we cannot abide by their rules
[16:38:19] <blackorzar> I guess they ask to avoid calls to local files and network ports without using their api
[16:38:20] <marshall_law> yeah
[16:38:34] <marshall_law> did Josh mention any of the work he did to get titanium up and running for the app store?
[16:38:56] <fairwinds> right
[16:38:57] <marshall_law> this was pre-Mountain Lion
[16:39:14] <fairwinds> no but we can review history of commits worse case
[16:39:28] <fairwinds> http://developer.apple.com/library/mac/#documentation/Security/Conceptual/AppSandboxDesignGuide/AboutAppSandbox/AboutAppSandbox.html
[16:39:53] <fairwinds> there are a couple of diagrams to give high level idea
[16:41:18] <fairwinds> So concerns will be how to implement in such a dyanmic circumstance
[16:41:29] <fairwinds> dynamicc
[16:41:45] <fairwinds> dynamic even
[16:42:49] <fairwinds> to that we are building in some sort of restrictions
[16:43:04] <fairwinds> that work together with app development
[16:43:22] <fairwinds> is something that requires some thinking
[16:44:36] <fairwinds> so a bit of a necessity to dig in here. This was sort of left by Appc for long time as an unresolved issue
[16:45:00] <fairwinds> with understanding Apple would be going this direction
[16:45:04] <marshall_law> hrm interesting
[16:45:31] <marshall_law> I think the main problem would be bundling webkit / chromium
[16:45:39] <marshall_law> you wouldn't be allowed to
[16:45:43] <marshall_law> you'd have to use the system webkit
[16:45:59] <marshall_law> in which case, you'd be excluded from using chromium embedded (though I may be wrong about that)
[16:46:02] <fairwinds> yes, josh and i talked about his a bit
[16:46:12] <fairwinds> briefly
[16:48:42] <fairwinds> I think the issue is that this thinking is not today and we deal with initial upgrades of libs first and analyse our requirements carefully on the apple sandboxing issue
[16:49:32] <fairwinds> I would like to have another discussion as we have had more time to consider this and some possible paths
[16:50:27] <marshall_law> fair enough
[16:50:28] <fairwinds> as we getting past the upgrading
[16:50:57] <fairwinds> my hope is that at that time we are more concrete about some possibitities
[16:51:34] <fairwinds> and from an implentation perspective we can consult on this with you
[16:51:37] <marshall_law> so WRT CI -- Appcelerator's Desktop CI never was complete. getting the windows environment specifically to build consistently was a pretty tough task. I never could nail it down
[16:52:04] <marshall_law> mainly due to the images we were using from EC2 I think, but I don't recall details. there were environmental issues
[16:52:13] <marshall_law> sure
[16:52:39] <fairwinds> heh, I have some fun with scons with environment on msvc10 express
[16:52:44] <marshall_law> I would highly recommend Jenkins though -- it's a great free / open source CI server and supports slave nodes and just about anything you can throw a stick at with plugins
[16:52:47] <fairwinds> there is a bug
[16:53:06] <fairwinds> yes, we are implementing jenkins and also looking at bamboo
[16:53:16] <marshall_law> Jenkins is really simple
[16:53:18] <marshall_law> I like it
[16:53:26] <marshall_law> here's my git URL, here's my shell script
[16:53:34] <marshall_law> :)
[16:53:44] <fairwinds> yes, I have some experience with jenkins also
[16:53:47] <fairwinds> for sure
[16:53:57] <marshall_law> I like it's utilitarian approach
[16:54:03] <fairwinds> yup.
[16:54:50] <fairwinds> i just look at outline to see where we are
[16:54:52] <fairwinds> one sec
[16:55:44] <fairwinds> right I think we have talked a little about the challege of the code base for complexity and new developers
[16:56:14] <fairwinds> do you have any specific advice about bringing them up to speed. How was Appc dealing with this?
[16:56:32] <marshall_law> great question
[16:56:35] <marshall_law> we weren't
[16:56:35] <marshall_law> :)
[16:56:39] <fairwinds> haha
[16:57:05] <fairwinds> was into the deep end straight away, sink or swim
[16:57:16] <marshall_law> we had a few outside contributors, but Josh was the only one that substantially stuck around and figured it out despite our lack of good documentation / help hehe
[16:57:30] <marshall_law> and we hired him, so :)
[16:58:12] <blackorzar> jaja great!
[16:58:13] <blackorzar> :D
[16:58:17] <marshall_law> I honestly think the community would be well served by architecture and API documentation
[16:58:22] <fairwinds> hehe, i see. We hope to improve process with an orientation of architecture etc and a process where new devs will be assigned small bug fixes to start
[16:58:35] <fairwinds> as they gain experience they take on more
[16:58:36] <marshall_law> yeah that sounds great.
[16:58:41] <marshall_law> yup.. I like it!
[16:58:48] <fairwinds> super
[16:59:20] <fairwinds> are there any docs that may not be available publicly that you believe could aid with this
[17:00:13] <fairwinds> ie. Were there any internal docs that we should be requesting if there is cooperation
[17:01:32] <fairwinds> blackorzar: you there?
[17:01:45] <marshall_law> h4mm
[17:01:46] <blackorzar> yeap
[17:02:06] <marshall_law> the only doc I could find was the old "building" documentation that's still up ..
[17:02:08] <fairwinds> k
[17:02:39] <marshall_law> fairwinds: you might ask Appc for any old desktop docs that were in the developer.appcelerator.com/docs folder
[17:02:52] <marshall_law> I'm not 100% sure what was in there to be honest, could be valuable stuff
[17:03:03] <fairwinds> k, cool
[17:03:44] <fairwinds> I think blackorzar may have some questions about some challenges we have had with drillbit
[17:03:59] <marshall_law> sure
[17:05:01] <blackorzar> marshall_law: my questions are more related to current status
[17:05:15] <blackorzar> but it would be helpful to know the architecture
[17:05:29] <marshall_law> status as in, should all the tests be passing?
[17:05:55] <blackorzar> we are dealing with the update webservice right now so none is passing
[17:06:06] <marshall_law> ahh gotcha
[17:06:15] <blackorzar> i see there is the drillbit app where you can select the tests
[17:06:39] <blackorzar> then there is the test_harness that i think it is produced from the previous selection
[17:06:47] <blackorzar> and finally the actual run 
[17:06:55] <blackorzar> Am i right?
[17:07:21] <marshall_law> blackorzar: yup. actually the test_harness is generated for each separate test suite ("box" in the drillbit UI)
[17:07:45] <marshall_law> that way if one suite crashes, it doesn't bomb the entire test run
[17:08:08] <blackorzar> what happens when there are more than 1 test suite selected? the test_harness is generated in a secuencial way?
[17:08:34] <marshall_law> blackorzar: yeah that's right. the test_harness inside Drillbit is more of a template, that gets copied for each suite
[17:08:42] <blackorzar> k
[17:08:55] <blackorzar> then i see the sdk is copied in the Drillbit folder
[17:08:59] <marshall_law> tiapp_harness.xml is the test harness's tiapp.xml
[17:09:14] <blackorzar> ok that's a good tip
[17:09:30] <marshall_law> blackorzar: yeah, that sounds right :) I don't remember all the details.. hehe
[17:09:42] <blackorzar> ok i will try to keep the question general
[17:09:51] <marshall_law> no worries, I will try my hardest to think on it too
[17:10:05] <marshall_law> basically...
[17:10:14] <blackorzar> the drillbit selector uses a runtime and the actual test another? 
[17:10:34] <blackorzar> selector = visual box chooser
[17:10:37] <marshall_law> for each test suite, drillbit will copy the source code, and do some code injection so that errors have helpful line numbers, and failures can be isolated to specific assertions/tests
[17:11:11] <blackorzar> cool 
[17:11:37] <marshall_law> blackorzar: I believe drillbit and the test harness run on the same runtime, but there might be a way to use a different runtime with the harness. I can't remember if there's a way to be honest
[17:12:30] <marshall_law> one of the problems obviously is that drillbit depends on the desktop sdk itself :)
[17:12:43] <blackorzar> ok... what is the best approach to debug dillbit / the sdk itself?
[17:13:01] <marshall_law> it may be better in the future to use a separate testing environment/system to keep things isolated
[17:13:15] <blackorzar> nice advise
[17:13:19] <marshall_law> blackorzar: great question! debugging javascript or the native code
[17:13:26] <marshall_law> ?
[17:14:09] <marshall_law> usually the best way to start debugging just about any problem is in the web inspector, because you can call titanium APIs on demand there
[17:14:15] <blackorzar> javascript that is been tested... i'm using some logs
[17:14:27] <marshall_law> even if there is some native problem, you can pare down the API call that causes it easier that way
[17:14:48] <blackorzar> good
[17:15:04] <blackorzar> did you use some debugging attch to process techinique?
[17:15:09] <marshall_law> blackorzar: by default, you should be able to right click on a desktop app built from scons and go to "Inspect Element" or whatever to open the web inspector
[17:15:26] <blackorzar> yeap i have gave it a try :)
[17:15:42] <marshall_law> for attaching, you can use the standard methods in gdb or Visual Studio
[17:15:48] <blackorzar> but then in the inspector I am not sure about its capabilities
[17:15:56] <marshall_law> inspector is a purely JS world
[17:16:03] <marshall_law> so it's useful for debugging JS problems ;)
[17:16:08] <blackorzar> k with the ti exposed
[17:16:11] <marshall_law> yup
[17:16:15] <blackorzar> great
[17:16:20] <marshall_law> but, it does have breakpoints etc
[17:16:24] <marshall_law> so it can be very useful
[17:16:44] <blackorzar> sure it does :)
[17:16:59] <blackorzar> should i be able to debug the js tests on the drillbit's web inspector?
[17:17:19] <marshall_law> you can also run any titanium executable through gdb directly..
[17:17:33] <marshall_law> gdb Drillbit.app/Contents/MacOS/drillbit
[17:17:45] <blackorzar> oks nice! jeje
[17:17:54] <marshall_law> blackorzar: you won't be able to do that unfortunately, since each test runs as it's own app
[17:18:25] <marshall_law> blackorzar: your only option there is to insert some async test that doesn't return, then you can inspect from the new app that opens up :)
[17:19:03] <blackorzar> oks, nice!
[17:19:04] <blackorzar> jaja
[17:19:58] <fairwinds> I think this has been super helpful
[17:20:48] <blackorzar> sure it does!
[17:20:57] <blackorzar> and a lot of homework! jajaja
[17:21:21] <fairwinds> we have really talked about the widest range of everthing related to tiDesk. I think finally I should open for any last questions.
[17:22:01] <fairwinds> For folks tuned in, this would be your chance to jump in
[17:22:37] <fairwinds> Any other questions for marshall?
[17:22:48] <marshall_law> hehe
[17:23:05] <blackorzar> Sure: How was the process to have Tidesktop integrated to tistudio
[17:23:40] <blackorzar> I think the project will not supported there, but still interested on the main challenges and current way to integrate
[17:23:47] <marshall_law> that's a good question -- as far as I know, the only real integration was with the web-service / release infrastructure so TiStudio gave users an update when a new version of the SDK was avaialable
[17:25:39] <marshall_law> one thing I'm having trouble remembering is whether or not TiDe had a project template like mobile does
[17:25:45] <marshall_law> so a new project can be created easily
[17:25:52] <marshall_law> that might be something you guys need to do
[17:25:57] <blackorzar> so, you can create TiDesktop projects, update the sdk, run them, (debug on webinspector), network package?
[17:26:10] <blackorzar> agree!
[17:26:24] <marshall_law> ah yes network packaging
[17:26:26] <blackorzar> Matt__: we are on open QA part of the session
[17:26:28] <marshall_law> that was part of the web-service
[17:26:59] <marshall_law> blackorzar: one thing we talked about earlier was the need for you guys to basically re-invent that :)
[17:27:14] <Matt__>  blackorzar thanks, my connection is spotty so I'm just listening
[17:27:18] <blackorzar> Yeap we will check that part :)
[17:28:37] <fairwinds> Are there any other final questions for Marshall?
[17:28:57] <blackorzar> marshall_law: If we move to chromium, we need to rewrite the tidesk-webkit patch? or it could be reusable?
[17:29:27] <marshall_law> hrm great question. you might need to change it so that the webkit APIs we added are exposed through chromium
[17:29:52] <marshall_law> could just be further chromium changes (not necessarily changes of our patches) -- but that depends on a lot of factors probably :)
[17:30:26] <marshall_law> if you guys are keen on dropping other language support entirely, you may not even need our patches
[17:30:50] <fairwinds> I don't think we want to do that
[17:31:06] <fairwinds> I think a reduction is prudent though
[17:31:29] <blackorzar> jajaja Marshall.. i'm a groovy fan... what if i want to add a new language? :P
[17:31:40] <marshall_law> kk
[17:32:07] <marshall_law> blackorzar: have fun bridging the JVM to Kroll .. that was one feature I'm glad I never had the chance to get to ;)
[17:32:51] <blackorzar> jaja good, but it's only modifications on kroll? or i should be keeping an eye on other parts on the project?
[17:33:16] <marshall_law> blackorzar: yeah, should only be a new language module in kroll/modules
[17:33:40] <marshall_law> groovy is on top of the JVM though, so you'd essentially be bridging Java:)
[17:34:11] <blackorzar> that's right
[17:34:48] <marshall_law> you might as well just use coffeescript
[17:34:48] <marshall_law> =P
[17:34:55] <blackorzar> Maybe a basic question here... how are the manifest files generated? are they inserted manually?
[17:35:17] <marshall_law> ahh good question!
[17:35:33] <blackorzar> jajaja :P 
[17:35:35] <marshall_law> blackorzar: yeah I think that is part of project creation
[17:36:05] <marshall_law> basically it is a property file
[17:36:10] <marshall_law> component-name: component-version
[17:36:12] <blackorzar> oky good
[17:36:30] <marshall_law> component-name == (sdk, runtime, (module name))
[17:36:36] <blackorzar> yeah, when updating the versions that will be a place to be careful
[17:36:41] <marshall_law> yup
[17:37:03] <marshall_law> it's kind of like a crude package.json , if you're familiar with npm
[17:37:40] <blackorzar> There are doc on the purpose for most of the modules, but i have questions on: App, Codec, monkey, Platform and Worker
[17:37:50] <marshall_law> :)
[17:38:07] <fairwinds> for sure, I often wondered why they did not use json instead of xml
[17:38:15] <marshall_law> I need to get running actually, maybe any further questions at this point could be sent by email?
[17:38:36] <fairwinds> Well I think we are about to wrap up. I want to thank you marshall for graciously giving your time and support to the project so that we could gain from your insights. We have learned quite a bit more today.
[17:38:58] <blackorzar> This was great! Thanks Marshall!
[17:39:03] <fairwinds> As we work through the code base and approach the sandboxing challenge, I hope we may count again on your insight. We certainly invite you to drop in at any time and have truly enjoyed our time today
[17:39:07] <marshall_law> you're welcome, it's good to see you guys taking the mantle :)
[17:39:18] <marshall_law> sure thing!!
[17:39:28] <fairwinds> heh, you've been great thanks
[17:39:29] <marshall_law> I will come bug you guys from time to time ;)
[17:39:38] <fairwinds> awesome
[17:39:43] <blackorzar> jajaja great!
[17:39:54] <marshall_law> blackorzar: any module specific questions you have feel free to just send them to me on the list, I'll try to get to them
[17:40:28] <fairwinds> that is an awesome offer, thanks
[17:40:54] <fairwinds> I also need to eat, I am starving :-)
[17:41:36] <marshall_law> hehe
[17:41:41] <marshall_law> have a good one guys :)

Copyright and Attribution

The following copyright and attribution applies to this document:

• Copyright © 2012 David Pratt (for TideSDK). All rights reserved.

CONTRIBUTORS:

• Paco Zarate (blackorzar)
• Matthew Hershberger