No subject
Thu Feb 24 17:58:36 CET 2011
minor issues we didn't like, such as preferring our current naming
convention to groundhog's, in which 'Field' is appended to every field
instead of pre-pending the table name. The main thing we didn't like about
Groundhog is its support for Sum data types, which is a neat feature, but
complicates the rest of the persistence library, and makes some other
functionality more difficult. There are also a few other implementation
differences.
The direction we want to take Persistent is to incorporate all the good
features. This means breaking the current API to make a much nicer one. We
plan on providing an upgrade script, much like the upgrade script from
hamlet 6 to 7. After Yesod hits 1.0 we will be much more careful to change
APIs, all the more reason to make some more drastic changes now.
Boris was even kind enough to offer his help in incorporating these features
in into Persistent. But 1) he wants to see how it all shakes out first and
2) we don't want to limit his excellent experimentation, so there will be no
official merge now. We will continue to try to standardize the APIs of the 2
packages.
# Future Meeting Technologies
Text meetings can seem a bit laborious at times, although it makes it easy
to write this summary. Particularly if we want to hack on some code, it
would be much nicer to have audio. I tried out the EVO conferencing tool
that was suggested. From a UI standpoint it was a craptacular Java Servlet.
It does seem quite featureful, although audio did not work by default on my
Ubuntu computer, and the window was annoyingly shaky, possible it doesn't
like XMonad. It also uses quite a bit of CPU. So I don't think this is a
good solution.
I am open to other suggestions. Here are others that I found, but have not
tried yet:
* https://www.webhuddle.com/
* http://www.openmeetings.de/
Otherwise, we will just do skype breakout sessions as needed.
# Future meeting times
I created a doodle that people can mark time on next week:
http://doodle.com/av92qzmvwyh48hcs
Doodle isn't really setup well for large ranges of time though.
--000e0cd6b40c36f13504a6142ccb
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div># Groundhog</div><div><br></div><div>We discussed Persistent and Groun=
dhog with Boris, the author of Groundhog who was kind enough to show up and=
meet with us.</div><div><br></div><div>The differences were summarized:<di=
v>
<div>* groundhog uses gadts to greatly clean up PersistEntity, and to avoid=
the need for a bunch of associated types and extra constructors.=A0downsid=
e: gadts + type families is a ghc 7 feature, although it might be possible =
to use phantom types and support ghc6</div>
</div><div><div>* persistent requires all datatypes be defines through its =
QQ syntax, groundhog allows types to be declared as normal.=A0i think this =
allows persistent to sidestep a lot of sticky naming issues, but groundhog =
is more flexible</div>
<div>* groundhog supports "and" and "or", persistent on=
ly supports "and</div></div><div>* groundhog use operators, persistent=
uses constructors</div><div>* groundhog supports=A0complex arithmetic expr=
essions</div>
<div>* groundhog supports comparing fields to fields</div><div><br></div><d=
iv>From a Persistent standpoint we want all of these features. There are a =
few minor issues we didn't like, such as preferring our current naming =
convention to groundhog's, in which 'Field' is appended to ever=
y field instead of pre-pending the table name. The main thing we didn't=
like about Groundhog is its support for Sum data types, which is a neat fe=
ature, but complicates the rest of the persistence library, and makes some =
other functionality more difficult. There are also a few other implementati=
on differences.</div>
<div><br></div><div>The direction we want to take Persistent is to incorpor=
ate all the good features. This means breaking the current API to make a mu=
ch nicer one. We plan on providing an upgrade script, much like the upgrade=
script from hamlet 6 to 7. After Yesod hits 1.0 we will be much more caref=
ul to change APIs, all the more reason to make some more drastic changes no=
w.</div>
<div><br></div><div>Boris was even kind enough to offer his help in incorpo=
rating these features in into Persistent. But 1) he wants to see how it all=
shakes out first and 2) we don't want to limit his excellent experimen=
tation, so there will be no official merge now. We will continue to try to =
standardize the APIs of the 2 packages.</div>
</div><div><br></div><div><br></div><div># Future Meeting Technologies</div=
><div><br></div><div>Text meetings can seem a bit laborious at times, altho=
ugh it makes it easy to write this summary. Particularly if we want to hack=
on some code, it would be much nicer to have audio.=A0I tried out the EVO =
conferencing tool that was suggested. From a UI standpoint it was a craptac=
ular Java Servlet. It does seem quite featureful, although audio did not wo=
rk by default on my Ubuntu computer, and the window was annoyingly shaky, p=
ossible it doesn't like XMonad. It also uses quite a bit of CPU. So I d=
on't think this is a good solution.</div>
<div><br></div><div>I am open to other suggestions. Here are others that I =
found, but have not tried yet:</div><div>*=A0<a href=3D"https://www.webhudd=
le.com/" target=3D"_blank">https://www.webhuddle.com/</a></div><div>*=A0<a =
href=3D"http://www.openmeetings.de/" target=3D"_blank">http://www.openmeeti=
ngs.de/</a></div>
<div><br></div><div>Otherwise, we will just do skype breakout sessions as n=
eeded.</div><div><br></div><div><br></div><div># Future meeting times</div>=
<div>I created a doodle that people can mark time on next week:=A0<a href=
=3D"http://doodle.com/av92qzmvwyh48hcs">http://doodle.com/av92qzmvwyh48hcs<=
/a></div>
<div>Doodle isn't really setup well for large ranges of time though.</d=
iv>
--000e0cd6b40c36f13504a6142ccb--
More information about the web-devel
mailing list