[Pipet Devel] Greetings from dLoo + answers to questions

[Brad Chapman]

[...trying to move the whole dLoo thread to the mailing list where it 
belongs, sorry to be so disjointed and include messages from 
everywhere...]

Nile wrote:
> Greetings from dLoo,

Hey Nile. Thanks much for writing and for the time you guys took in 
preparing the "gray papers." It is very nice to have someone spending 
time looking at Piper ideas enough to write up documents like those, 
so that is very cool, and much appreciated. 
    In addition, thanks for all of your responses to Jeff's questions 
concerning licensing and your company and all of that stuff. I'll 
admit that I'm one of the people with a lot of concerns about working 
with a company. In general, companies and business in general make me 
feel sick to my stomach, but dLoo's hands off approach sounds very 
cool, and since you guys aren't that big, I guess I can leave you off 
my list of companies to destroy and burn :-). Seriously, the kind of 
informal relationship Nile was proposing sounds really good.

Nile wrote:
> So, I have a serious question for you. We're looking at the 
"gifts"/"grants"
> approach to avoid these effects? What do you think of this? Is it
> sufficient? In
> short, what is the best way for a cash-poor company to support open 
source
> developers?

I don't really know if I am a good person to be answering this type of 
question, since I don't need to make any cash from open-source 
programming (at least right now :-). In addition, I'm not too positive 
I feel very comfortable speaking for any part of the open source 
community. Maybe stuff like this would be good to bring up on some KDE 
and Gnome lists? It seems like there are always lot of people ready to 
spout off about their open source ideas, and this might manage to grab 
people more from the "mainstream" open source community, whereas I 
feel like I am kind of on the fringe.

Nile wrote:
> We are learning a lot over here. One thing the community really 
lacks right
> now is a document that explains how companies should work with Open 
> Source. E.g., a FAQ that has answers to the question "How should a 
> company contribute to an open source project?" or "How should a 
company 
> collaborate with an open source team?"

This is a hard question to answer in general since it probably varies 
a lot from person to person and project to project. For me, I would 
just be happy to be coding on open source projects alongside people 
from companies. I don't really understand any of the details of how a 
buisness works and stuff, but it seems like the best way to have a 
company collaborate with an open source "team" is just to have people 
from the company coding/talking about the project, just like any other 
random person. One thing about open source is that no-one should 
really "control" it (of course, as Nile mentioned, this doesn't always 
happen, like in the case of Mozilla). The project is more about a 
bunch of people with similar ideas coming together, coding, and 
producing a product without any restrictions on it. So I would be more 
than happy to code along any with anyone, even if they are from a 
company.
    I guess the mess comes in when people need to use the product to 
make money, and this is where I am not really 100% sure what the 
company needs to do and how this will affect the relationship of a 
person from a company and an open source team.

    So I don't know if any of that rambling was any help on that, but 
now I'll talk about something more important, Piper and 
dLoo/BlueBox collaboration :-)

> ---On Collaborating as a Whole---

Gary wrote:
> So here we are considering another
> collaboration, which means another rewrite of our defiinition layer 
to
> hook into the bluebox system. 

Gawd no! Excuse me for a second while I get a couple of shots of "Old 
Crow" to deaden the pain here....
    Seriously, I do not mind rewriting the dl to incorporate new code 
(even tho I bitch and moan about it all of the time). I have got so 
many cool ideas from Jarl and Jean-Marc's stuff and I think Piper is 
benefiting greatly already from their contributions. Hopefully soon 
we'll have hooked a lot more of their code into all of this and this 
will be really apparent in actual functionality :-).
    But the dl is written in python, which is meant for re-writing and 
messing around with things (if it was in C++, I definately would have 
gone completely insane by now), and we should take advantage of that 
to try to hook more stuff in, if we can. Sigh, did I really say that? 
:-)

Gary wrote:
> We stand to benefit from the expertise of
> the dLoo programming team, and the codebase that they have produced. 
 

Agreed, there are tons of good ideas there, and it is definately 
easier to hook in good ideas than to write 'em from scratch. I don't 
really 100% understand what dLoo "wants" from Piper, but if we can 
take advantage of code they have, this is really super.

Gary wrote:
> But
> without having a good look at that codebase, it is hard to guage how 
much
> work we would be required to do in order to justify the 
collaboration.  So
> before we can commit to a collaboration, I think we need to have 
some idea
> of the extent of revision we will have to do in order to integrate 
> bluebox and piper.

Agreed completely. It is hard to talk about anything without seeing 
actual code and functionality and figuring out where it'll go. I'm 
presuming that BlueBox is written in C++, and I've already gotten SWIG 
to generate working bindings for Jean-Marc's code, so technically this 
hopefully won't be too much of a problem (as long as they don't use 
too much STL, ugh!).
    However, I think our number one priority should be getting 
Overflow and GMS integrated with what we've got in Piper. This is 
really coming along thanks to Jarl and Jean-Marc's hard work, and I 
want them to be able to have something working as soon as we can. 
    It seems like this isn't too bad with BlueBoxes time frame, since 
there won't even be an initial release until later this month. So that 
should give us time to figure out how we are going to actually work 
on integrating the two projects together while we work more on getting 
Overflow, GMS and Loci all together into Piper. It would definately be 
great to see BlueBox code as soon as we can, so we can try to migrate 
what we have to fit it, and make things less painless.
    But, damn, who is going to do all this work I just talked about? 
:-)

Nile wrote:   
> ---On the Gray Papers---
> 
> What we have been doing over here the last two days is putting 
together
> a set of gray papers (not white) on how BlueBox works, how we 
understand
> Piper to work, and how they could work together with directory 
services.

Again, thanks for doing this! It seems like quite a bit of work and is 
much appreciated. Here's my thoughts/comments on particular pages:

1. The Piper screenshots on dev_graypapers_piper.html 
and dev_graypapers_user.html -> These screenshots are crustily old 
(did Piper/Loci ever even look like this, or is this all just 
mockup?). Can we give the dLoo guys some real screenshots from what we 
have now that shows the same stuff? I can do this, but am probably not 
the best person to since my artistic skills are nearly nonexistant. 
This way we can also show multidimensional components in action and 
everything.

Another point on this. I *hate* the screenshot/mock-up with the 
"MultiSeq" sequence alignment node on it, just because it isn't even 
close to a good reflection of the functionality we have in Piper right 
now. If we want to use this, I would be much happier if it was clearly 
labelled as just being a photoshop job and not reflecting current 
functionality. I just think it gives people the wrong idea about what 
we've got.

2. The mention of a "XML component language" at the top 
of 'dev_graypapers_piper.html' and 'dev_graypapers_user.html' -> I am 
kind of nervous about calling this "a complete language" since the XML 
here is really simplistic. Right now we are just modeling each 
node/locus as having three items: Parameters, Inputs, and Outputs, and 
trying to make things fit in as having only these three items. I don't 
know if we can make any promises that this is scalable to incorporate 
"any component" that exists, since we just started using this new 
language a couple of weeks ago :-). This is all based on functionality 
that already exists in Overflow, so it is very promising to work well 
(at least, I hope so), but maybe we could talk a bit about this "three 
component model" or whatever and mention that is what we are doing. I 
could write something short up on this if you all want...

3. On the DSML stuff at 'dev_graypapers_dsml.html' -> For the Status 
part, unfortunately no actual code exists in Piper to support 
networked connections and sharing of directory services :-<. Sorry 
to disappoint. Right now we've been focusing on local stuff only (even 
though my real interest in this is in the networking). How the 
networked stuff is proposed to work is semi-sketeched out in the docs 
on the Definition Layer. I was hoping this wouldn't be too horrible to 
implement since it would be built off the framework that already 
exists in the definition layer (so at least it wouldn't be from 
scratch) but I'm afraid I can't claim that a single line of code is 
specifically devoted to networked connections :-<.
    Since this is the case, I had a nice read through the DSML spec 
that Nile et al. reference on this page (Minor rant--why can't they 
have one example in this stupid spec that doesn't have ugly 
namespaces cluttering it up? :-) and it seems like a really cool way 
to mark-up available directories (well, nodes or loci in the case of 
Piper) and what kind of functionality they have. If you guys at dLoo 
have a plan sketched out for how you want to incorporate the remote 
directory services, it would be really nice to be able to talk through 
this and see if we can bounce ideas off of each other.

    Okay, I'm going to stop writing now. If you made it all the way to 
here, you should definately give yourself a bit fat gold star. Thanks 
much for reading.

Brad