Skip to Content.
Sympa Menu

pcplantdb - [pcplantdb] Re: So on and so forth

pcplantdb@lists.ibiblio.org

Subject: pcplantdb

List archive

Chronological Thread  
  • From: Chad Knepp <pyg@galatea.org>
  • To: pcplantdb@lists.ibiblio.org
  • Subject: [pcplantdb] Re: So on and so forth
  • Date: Tue, 2 Mar 2004 17:58:10 -0600

Gosh I love how John explains things.

John Schinnerer writes:
> Aloha,
>
> > The programing isn't the hard part. The hard part is
> > understanding and documenting those relationships. The
> > programing part of Eden and PFAF is nothing compared to the data
> > assimilated by Ken Fern.
>
> Ditto, more or less - though designing what to program, in terms of
> the more complex proposals heard here, will not be trivial IMO.
>
> I missed something re the Ken Fern reference...please enlighten me
> about him...?

Ken Fern did most/all of the data collection in the PFAF dataset,
somewhere around 8-10 years of [uncompensated] work... Actually
Richard Morris probably has a more accurate answer, but he's pretty
much one of my heros.

> Also, to Stephanie's question, the short answer is yes. To
> hopefully clarify in mostly plain English the way this might be put
> together:
>
> You can cerainly have the graph-based front end (if someone steps
> forward to develop it), and others as well, but there has to be
> something behind them.
>
> The 'back end' is the database itself and the ways and means to
> access it at the programming level. It does *not* include any
> particular 'user-friendly' or 'end-user' interface of any kind. It
> does include some (hopefully) programmer-friendly ways and means to
> get information out and put information in. In geek-speak, these
> ways and means are usually called an application programming
> interface (API). So a back end typically consists of the actual
> database itself and an API that 'front end' programmers can use to
> talk with that database.
>
> The 'front end' is what the user sees when they go to some web site
> that provides access to the back end. Programmers create a 'front
> end' using some typically visually oriented model (windows, forms,
> icons, buttons, mouse point-and-click, graphical representations
> and so on) to help an end user do what they want with the back end
> - such as ask for and receive information.
>
> Good software design means that the back end does not assume or
> enforce a particular front end. A front end developer looks at the
> ways and means provided by the API for the back end and uses them
> to essentially translate between the end users' actions, made via
> some graphical user interface, and the database itself.
>
> One person or group could write a typical sort of web-form-based
> user interface front end for searching the database. Another could
> write the dynamic-graph sort of user interface that you favor for
> searching the database.
>
> One back end - many possible front ends. Front ends need back end,
> including well-formed and reasonably stable API, to be built at
> all.
>
> Hope this helps to explain why IMO discussing front ends without
> having a back end well under way is not a good use of our
> bandwidth.

Yup. There is some level of flexibility regarding where the front end
meets the back as well. One can describe the API as being how the
front end interfaces directly with the database and place the majority
of the responsibility in the front end. Alternately one can place
some code between the front end and the database and describe the API
as the interface of the front end with this glue layer. This allows
some of the complex and common operations to be shared among front
ends and enforces specific interactions with the database. I favor
the later because I'm paranoid about data-munging and I think an
appropriate abstraction of the back end mechanics will make writing
front ends flexible, powerful, and easy. I also think I'm a good
choice to implement the back end code and am open to accommodating the
needs, desires, and whims of front end coders in the back end. How
high do you want it to jump?

> > Because, wonderful news, we were accepted into the final round of
> > the grant process with the Threshold Foundation. But it seems we
> > are re- questioning the proposed project - are people still
> > comitted to pursuing this? And if so, are there any changes we
> > would make to the initially proposed project?
>
> That's cool.
> What do you consider to be the initially proposed project? If
> there's money to pay me I am more available than if not (because if
> not I have to be doing something else with my time for livelihood).
> I would be able to start setting up a test/QA infrastructure,
> process and bug DB (bugzilla or similar open-source issue tracking
> system).
>
> Has someone already stepped forward to handle and host source
> control if/when some design and coding starts in earnest?

I'm partial to cvs (Concurrent Versions System <http://cvshome.org>)
and am willing to manage it at galatea.org or wherever. Like most
things Unix, it is extremely powerful and rather intimidating to new
users. I use cvs for Eden already.


Stephanie Gerson:

I can't quote unicode very well, so I'll just answer without context.

I think Eden represents a good design. It could be extended or
completely rewritten; there really isn't that much to it... I wrote it
in less than a week. One of the prominently missing features is any
form of collaborative input/editing, which I think is highly important
but a tricky thing to do well. I personally am not satisfied with any
wiki I've seen so far. As John implies, a Guild Design Application
could easily be a front end for an adequately developed back end.

In terms of the grant proposal, I've reread it and although the title
seems to, IMO, overemphasizes the element of guild design, most of the
rest of the proposal seems right on target with my own vision.

I do have a strong philosophical objection to participating in any
project creating intellectual property where the product is not free
as in open source (google for "reasonable use"). Initially my
objections, and my reluctance to participate, where around the choice
of Thinkmap as a core part of the project. Although that has changed
there is still the item of licensing images from PFAF. I am willing
to buy the images from PFAF but I am not OK with encumbering the
project with non-free IP. For that matter, I think it would be a nice
token to buy the PFAF dataset (even though it is free already) to
compensate them for their efforts.

Other than that, I think the proposal could use a dedicated programmer
on staff ;-) Guess who I'm thinking of?


I'd be pleasantly surprised if the proposal was accepted, but I'm not
expecting it. I'm curious about peoples level of commitment to
proceeding without funding. I think we could accomplish all of this
in 5 years time if we put in 150 hours or so a year. I am committed
to developing Eden even if I remain the only one. Anyway...


Chad

--
Chad Knepp
perl -e 'print pack"H*","7079674067616c617465612e6f72670a"'




Archive powered by MHonArc 2.6.24.

Top of Page