response to RFC
robin
This is robin from algoma u and I've been working with Dan and Art et
al. on the Conifer Project. I've decided reserves would be a fun
place to start doing some development work and since there's a request
for comments, I thought I would be a good idea to start by going over
the RFC and adding some comments.
I've created said doc here:
It's long and viewed best by using the pdf bookmark feature to look at
individual areas of requirement (ie courses, items etc). There's a
google an accompanying doc of SQL code linked in the intro.
The code is more to outline what tables I imagine need creating then a
real implementation. I've assumed postgres because that's what I'm
familiar with. I've tried not to make any assumptions about interface
technologies at all, concentrating on the necessary data structures.
I'm hoping that once the data structure is sorted out, then the
interface development will be a lot easier.
Well, I'm looking forward to comments and feedback.
cheers,
robin
Graham Fawcett
On Fri, Jan 8, 2010 at 12:28 PM, robin <robin...@gmail.com> wrote:
> Hi folks,
>
> This is robin from algoma u and I've been working with Dan and Art et
> al. on the Conifer Project. I've decided reserves would be a fun
> place to start doing some development work and since there's a request
> for comments, I thought I would be a good idea to start by going over
> the RFC and adding some comments.
Thank you! And welcome to the discussion group (belatedly -- I'm very
sorry for not responding sooner).
I'm really looking forward to working with you to get Syrup ready for
Algoma. Evergreen integration was the next big issue for us, IMO, and
I'm happy to see that you're interested in Syrup as a solution.
Just to let everyone know: Art, Robin and I had a phone meeting on
Friday to talk about Robin's document and schema, and to figure out
our next steps. I think Art's going to set up an open Web meeting, to
provide a status-update on Syrup and a walkthrough of the current
version. Meanwhile, Robin and I have exchanged a few emails about his
design. (I hope we'll move the design conversation on-list, but I
didn't want to do that without your consent, Robin.)
What's clear is that we're restarting our efforts on Syrup. I believe
our goal is to have a working Evergreen integration by the end of the
current academic term. If any of you are interested in that outcome,
I'd encourage you to get involved and put your comments on the list.
Best,
Graham
robin
Sure, I've got no secrets, if you want to through out onto the list
what we've been discussing, please do so...
cheers
Robin
On Jan 17, 10:05 pm, Graham Fawcett <graham.fawc...@gmail.com> wrote:
> Hi Robin,
>
Graham Fawcett
On Mon, Jan 18, 2010 at 9:22 PM, robin <robin...@gmail.com> wrote:
> Hey Graham, thanks for the warm friendly hello!
>
> Sure, I've got no secrets, if you want to through out onto the list
> what we've been discussing, please do so...
Thanks. Our off-list exchange is below. Comments welcome.
Robin, as you said in follow-up, I think we're mostly on the same page
here.
Graham
Robin's initial message:
Hey there,
It was great meeting you Graham! Here are the few notes I jotted
down during the meeting. Let me know if you guys think they’re ok
and I’ll go ahead with them.
1. The next basic step is to go over the scheme I made to ensure it
doesn’t have any sql that might make Django grimace. (Graham)
2. Find a quick replacement for Karen on the circ committee and run
them through a refresher of Syrup (Art, Robin)
3. Create some google docs that outline the events that need to
happen to make a workflow go. (Robin)
4. Get the project manager from Equinox involved (Art)
Does this sound right, guys?
Robin
Graham's response:
Hi Robin,
(I will post a summary on the group of our off-list discussions, with
the hope that we might move our ongoing conversation there, without
completely baffling our group-members. OK?)
On Fri, Jan 15, 2010 at 2:03 PM, Robin Isard <Robin...@algomau.ca>
wrote:
>
> Hey there,
>
> It was great meeting you Graham! Here are the few notes I jotted
> down during the meeting. Let me know if you guys think they’re ok
> and I’ll go ahead with them.
Likewise nice to meet you! Thanks for capturing these notes. I've had
a better chance now to dig into your schema and your RFC document.
> 1. The next basic step is to go over the scheme I made to ensure it
> doesn’t have any sql that might make Django grimace. (Graham)
Maybe a little grimacing, but only at first. :-) We'll need some work
to accommodate the spanning of multiple schemas, a technique that
Evergreen embraces and Django cannot comprehend (being a database-
agnostic framework, it has no notion of Postgres-style schemas). But
it's surmountable, and with a little tweaking I think we could get
Syrup running inside an Evergreen database the way you've modelled it:
we just need to be more explicit about the naming of the tables behind
the Django "models," and we might need to run an Evergreen-specific
SQL script to create some constraints that Django itself wouldn't
impose.
My biggest concern relates to your note in the RFC document about
interoperability. Our initial goal was to make Syrup interoperable,
and that's influenced the design heavily: we planned to "integrate"
with Evergreen, not depend upon it, and your "Reserves 2.0 Goals" are
what we hoped to tackle in our "1.0". As a result, our schema
unfortunately lacks the "show me your data structures" quality,
because our runtime model depends on external, abstractly-specified
systems.
I think we're committed to interoperability at the core. Art has
raised good reasons why a product that can work outside of Evergreen
might enjoy a brighter future. I believe this implies that our schema
will always be a partial story: to understand the system's behaviour,
we'll need to read the external interfaces too. (And our external
interfaces are spottily documented at the moment -- sorry, I will
rectify that.)
You've derived a great schema for a Evergreen-based reserves system. I
think the non-Evergeen parts are very similar to their counterparts in
Syrup's schema (with some exceptions where your design is cleaner). I
guess my question is how we should address the Evergreen-specific bits
without making Syrup depend upon Evergreen.
One option would be to use the moral equivalent of conditional
compilation. In Django, the schema is derived from a "model", which is
just Python code written in a declarative style. We can have a core
model (courses, bcontainers, items) which is ignorant of Evergreen,
and a conditional Evergreen model that brings in dependencies on
existing Evergreen tables. (It would also declare an explicit
dependency on Postgres as a backend.)
When running Syrup in "Evergreen Mode," the Evergreen model would be
loaded, and some of the external-system dependencies (e.g. user
authentication, copy-information lookup, circ modifiers) will be
satisfied at the database level. Otherwise, only the core model is
used, and the external dependencies must be satisfied another way
(LDAP, SIP, OpenSRF, whatever).
Taking this avenue means that we would still model the core in Django,
and let Django write the SQL for the core schema. We're welcome to
ignore (or massage or annotate) Django's SQL output in Evergreen mode,
but in the absence of Evergreen we'll still allow Django to create a
working database from scratch.
I think my next step is to review the Syrup code, and write up a brief
document on the external interfaces we've assumed, and get your
feedback on those. I suspect even in Evergreen-mode, we'll still need
some non-database interactions? (Or do you think we won't need OpenSRF
because we're connecting right to the database?)
Thoughts?
Best,
Graham
robin
I'm thinking that in order to stay true to the standalone philosophy
of Syrup, in other words, to put interoperability front and center
(and I don't have any problem with that), all we really need to do is
combine the best of the original schema with the one I did, and run it
all in sqlite, as a native Django app. complete with Django admin
interfaces etc. Then all that's required is the creation of an
interface that allows different ILS's to talk to it. Because of it's
flexibility and simplicity (not just cause it's used heavily by
Evergreen -- but that is a happy accident) I'm going to suggest a JSON
service.
Python has a JSON library that can be used to send and receive
messages, this could be built into Syrup. On the other end, we simply
create a javascript library that wraps JSON calls in simple helper
functions like retrieve_item_by_isbn() which returns a JSON object
that the local sys admin (whomever that is) can work with and make
talk to their respective ILS (whatever that is). If necessary, we
could write simple libraries in perl and python too so a local sys
admin has their choice of language to work in. I don't think the
libraries would have to be very complicated.
What does the list think?
Robin
On Jan 21, 6:56 pm, Graham Fawcett <graham.fawc...@gmail.com> wrote:
> Robin wrote:
> On Fri, Jan 15, 2010 at 2:03 PM, Robin Isard <Robin.Is...@algomau.ca>
Dan Scott
> Hey there,
>
> I'm thinking that in order to stay true to the standalone philosophy
> of Syrup, in other words, to put interoperability front and center
> (and I don't have any problem with that), all we really need to do is
> combine the best of the original schema with the one I did, and run it
> all in sqlite, as a native Django app. complete with Django admin
> interfaces etc. Then all that's required is the creation of an
> interface that allows different ILS's to talk to it. Because of it's
> flexibility and simplicity (not just cause it's used heavily by
> Evergreen -- but that is a happy accident) I'm going to suggest a JSON
> service.
>
> Python has a JSON library that can be used to send and receive
> messages, this could be built into Syrup. On the other end, we simply
> create a javascript library that wraps JSON calls in simple helper
> functions like retrieve_item_by_isbn() which returns a JSON object
> that the local sys admin (whomever that is) can work with and make
> talk to their respective ILS (whatever that is). If necessary, we
> could write simple libraries in perl and python too so a local sys
> admin has their choice of language to work in. I don't think the
> libraries would have to be very complicated.
>
> What does the list think?
I don't have any allegiance to Syrup as a standalone application; I
just want a reserves system that we can actually use. I expressed my
concerns about the loosely-coupled approach to Graham and Art almost a
year ago, but set them aside then because I was convinced that we
would at least have a usable reserves system and I wasn't in a
position to contribute any code to the effort. However, I still have
reservations (heh) about building reserves as an independent app with
its own data store.
* A separate data store segregates data that could be extremely
useful to the rest of Evergreen in an academic context (instructor /
course / class mappings) into a separate database.
* A separate data store complicates reporting because there's no way
to use the Evergreen reporter module against the reserves data store.
Reporting is very much on my mind at the moment. One of the reports I
was recently asked to write was a count of the number of reserve
transactions, by course ID. I can do that in Evergreen today because
we're using bookbags to group the reserve items and can determine
whether an item was on reserve by its circulation modifier, but it's
tenuous. The only way that I could do that in the current Syrup model
would be to periodically suck the data in from the Django database
into a side table in the Evergreen database and craft custom SQL
queries to link in the pertinent data. Not fun.
At this point, I'm also concerned that we're also using technology
that doesn't fit with the rest of Evergreen: jQuery instead of Dojo,
Django-ORM instead of cstore / pcrud, SQLite instead of PostgreSQL,
Python instead of Perl or C. That broadens the surface for
vulnerabilities (umpteen more base modules to update) and reduces the
ability to reuse skills between Evergreen core and Syrup. Ironically,
the combination of not being integrated & foreign technology (PHP &
MySQL) was pretty much the rationale for not adopting and contributing
to the ReservesDirect community in the first place (which no longer
has any plans for continued development - RIP).
Luckily, the Evergreen SIP and Z39.50 interfaces that were extremely
weak bases to build on back when Syrup started, and that were chosen
as the point of integration with Evergreen, have firmed up
considerably since then (yes - we now accept and handle queries with
non-ASCII characters properly!). So there's that. But they're still
limited compared than their native Evergreen counterparts.
Robin - to make your proposal more concrete, can you model how a
typical reserves task would send and receive data between Syrup and
Evergreen? For example, a professor wants to place an item on reserve
for their course, starting next term. How do they do this, and how
does the item get from wherever it currently is to the reserves
location at the appropriate time, with a new temporary circulation
modifier, and with a new temporary call number? And then, when the
course is done, how does it get back to the correct location with the
previous circ modifier and call number? I think working through
something like this, with a description of the actions humans have to
take as well as identifying which OpenSRF calls we would have to make
(and where data is changing in both Syrup and Evergreen), would be
helpful.
--
Dan Scott
Laurentian University
Graham Fawcett
On Thu, Jan 21, 2010 at 10:30 PM, Dan Scott <den...@gmail.com> wrote:
>
> I don't have any allegiance to Syrup as a standalone application; I
> just want a reserves system that we can actually use. I expressed my
> concerns about the loosely-coupled approach to Graham and Art almost a
> year ago, but set them aside then because I was convinced that we
> would at least have a usable reserves system and I wasn't in a
> position to contribute any code to the effort. However, I still have
> reservations (heh) about building reserves as an independent app with
> its own data store.
>
> * A separate data store segregates data that could be extremely
> useful to the rest of Evergreen in an academic context (instructor /
> course / class mappings) into a separate database.
> * A separate data store complicates reporting because there's no way
> to use the Evergreen reporter module against the reserves data store.
> Reporting is very much on my mind at the moment. One of the reports I
> was recently asked to write was a count of the number of reserve
> transactions, by course ID. I can do that in Evergreen today because
> we're using bookbags to group the reserve items and can determine
> whether an item was on reserve by its circulation modifier, but it's
> tenuous. The only way that I could do that in the current Syrup model
> would be to periodically suck the data in from the Django database
> into a side table in the Evergreen database and craft custom SQL
> queries to link in the pertinent data. Not fun.
With respect to storage, there's still another option on the table.
Syrup's schema could live inside an Evergreen database. There would
be a little wrestling to do to get Django to cohabitate properly, but
it's certainly doable.
> At this point, I'm also concerned that we're also using technology
> that doesn't fit with the rest of Evergreen: jQuery instead of Dojo,
> Django-ORM instead of cstore / pcrud, SQLite instead of PostgreSQL,
> Python instead of Perl or C.
True, except for SQLite: that was *never* intended as a production
option. Django might not care, but I do. :)
> That broadens the surface for vulnerabilities (umpteen more base
> modules to update) and reduces the ability to reuse skills between
> Evergreen core and Syrup. Ironically, the combination of not being
> integrated & foreign technology (PHP & MySQL) was pretty much the
> rationale for not adopting and contributing to the ReservesDirect
> community in the first place (which no longer has any plans for
> continued development - RIP).
The skill-reuse argument is strong: no doubt there's a large gap
there. (Wasn't there another Python application in Evergreen when we
started working on Syrup? I didn't think we were the first.)
> Luckily, the Evergreen SIP and Z39.50 interfaces that were extremely
> weak bases to build on back when Syrup started, and that were chosen
> as the point of integration with Evergreen, have firmed up
> considerably since then (yes - we now accept and handle queries with
> non-ASCII characters properly!). So there's that. But they're still
> limited compared than their native Evergreen counterparts.
I'm glad for the improved services. But I don't think we've painted
ourselves into a SIP and Z39.50 corner. They're supported, but I've
tried to isolate them as implementation details and keep the lookup
services as abstract as possible. (It's still a work in progress, not
a work of beauty!) There are already OpenSRF calls in our current
codebase for barcode-lookup calls, because SIP is insufficient. (We
also have some hackish support for integration with the OPAC
through bookbag URLs and such.)
I guess my big question is: how much happier would you be if the Syrup
data were in an Evergreen database proper? Robin's proposed schema is
a good starting point for discussion, since he relates the reserves
schema to the EG schemas, and we've already invested some effort
together to consider how we'd do that integration.
We can't transmute Python into Perl, but I think the other issues are
surmountable. Where does that leave us?
Cheers,
Graham
> Robin - to make your proposal more concrete, can you model how a
> typical reserves task would send and receive data between Syrup and
> Evergreen? For example, a professor wants to place an item on
> reserve for their course, starting next term. How do they do this,
> and how does the item get from wherever it currently is to the
> reserves location at the appropriate time, with a new temporary
> circulation modifier, and with a new temporary call number? And
> then, when the course is done, how does it get back to the correct
> location with the previous circ modifier and call number? I think
> working through something like this, with a description of the
> actions humans have to take as well as identifying which OpenSRF
> calls we would have to make (and where data is changing in both
> Syrup and Evergreen), would be helpful.
>
> --
> Dan Scott
> Laurentian University
>
> --
> You received this message because you are subscribed to the Google Groups "syrup-reserves-discuss" group.
> To post to this group, send email to syrup-reser...@googlegroups.com.
> To unsubscribe from this group, send email to syrup-reserves-di...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/syrup-reserves-discuss?hl=en.
>
>
Art W Rhyno
I am in transporting The Beijing Bike Club around for a provincial championship (a local band and I am the default roadie as father of the drummer). My ears are ringing far too much for me to parse or speak to any of the weightier issues that have appeared on the list but I will try to resurrect the demo site on the conifer demo server on the weekend. I don't know if it makes any difference, but the Django instance that Graham architected varies quite a bit from a typical install in that it's wired into postgres, avoids the traps of Django's default templating language, and supports internationalization (and thanks to Graham for all of this, I could not have sorted this out). I am not enough of a python guru to know the gap between this combo and Bill Erickson's work in pylons - is there a big difference there? Although not all of the interest in syrup has come from Evergreen sites, I recognize that we are not under any obligation to produce a successor to Reserves Direct (I don't think we could remotely compete with Emory for resources anyway). My sense is that Windsor's enthusiasm for any reserves application is almost completely based on what is ready for use in early August, things could move along now here because of targeting a different semester. I can't remember everything about physical reserves but syrup had/has some very good plumbing for electronic reserves, that might worthy of a side project on its own if the sip/opensrf hybrid approach falls down.
art
Dan Scott
> Hi,
>
> I am in transporting The Beijing Bike Club around for a provincial
> championship (a local band and I am the default roadie as father of the
> drummer). My ears are ringing far too much for me to parse or speak to any
> of the weightier issues that have appeared on the list but I will try to
> resurrect the demo site on the conifer demo server on the weekend. I don't
> know if it makes any difference, but the Django instance that Graham
> architected varies quite a bit from a typical install in that it's wired
> into postgres, avoids the traps of Django's default templating language, and
> supports internationalization (and thanks to Graham for all of this, I could
> not have sorted this out).
Right, all of these are good things.
> I am not enough of a python guru to know the gap
> between this combo and Bill Erickson's work in pylons - is there a big
> difference there?
The big difference is that Bill's work in Pylons w/ the Mako
templating language ended up being a thin shell for an interface is
mostly written in Dojo, so he opted to reduce the number of
requirements for Evergreen core by shifting all of the corresponding
templates over to Perl's Template::Toolkit; ergo, the only use of
Python with respect to Evergreen today is for the "constrictor"
ILS-Contrib module that is used for load testing.
> Although not all of the interest in syrup has come from
> Evergreen sites, I recognize that we are not under any obligation to produce
> a successor to Reserves Direct (I don't think we could remotely compete with
> Emory for resources anyway). My sense is that Windsor's enthusiasm for any
> reserves application is almost completely based on what is ready for use in
> early August, things could move along now here because of targeting a
> different semester. I can't remember everything about physical reserves but
> syrup had/has some very good plumbing for electronic reserves, that might
> worthy of a side project on its own if the sip/opensrf hybrid approach falls
> down.
Right, perhaps our differences of opinion come from competing
priorities; we've never used an electronic reserves system at
Laurentian. We just wanted a simple interface that circulation staff
could use to shift physical items onto reserve and quickly add new
items (photocopies, professor's copies) to the system, without
requiring full-blown MARC editing and the volume / copy editor. And in
turn, we wanted to make it possible for students to quickly see the
list of items on reserve for their courses (by course code, professor
name, and course name).
Adopting an electronic reserves approach for the photocopies would
help us with a small part of our workload, but I think we would still
have a large complement of physical items to deal with.
Dan Scott
2010/1/21 Graham Fawcett <graham....@gmail.com>:
> Hey Dan,
>
> With respect to storage, there's still another option on the table.
> Syrup's schema could live inside an Evergreen database. There would
> be a little wrestling to do to get Django to cohabitate properly, but
> it's certainly doable.
That would help. To avoid having to have multiple Django instances and
copies of the schema inside the Evergreen database (I fear
syrup_OWA.course syrup_OSUL.course madness!), I guess we could add a
column to identify the owning library for each course/instructor?
>> At this point, I'm also concerned that we're also using technology
>> that doesn't fit with the rest of Evergreen: jQuery instead of Dojo,
>> Django-ORM instead of cstore / pcrud, SQLite instead of PostgreSQL,
>> Python instead of Perl or C.
>
> True, except for SQLite: that was *never* intended as a production
> option. Django might not care, but I do. :)
Well, I was responding here to Robin's suggestion to "run it
all in sqlite". I know you care :)
>> That broadens the surface for vulnerabilities (umpteen more base
>> modules to update) and reduces the ability to reuse skills between
>> Evergreen core and Syrup. Ironically, the combination of not being
>> integrated & foreign technology (PHP & MySQL) was pretty much the
>> rationale for not adopting and contributing to the ReservesDirect
>> community in the first place (which no longer has any plans for
>> continued development - RIP).
>
> The skill-reuse argument is strong: no doubt there's a large gap
> there. (Wasn't there another Python application in Evergreen when we
> started working on Syrup? I didn't think we were the first.)
Way back when, acquisitions was being built on Pylons/Mako/SQLAlchemy,
but that migrated some time ago to an almost purely Dojo interface on
top of very thin Perl Template::Toolkit templates. So Syrup wasn't the
first, but now it stands alone.
>> Luckily, the Evergreen SIP and Z39.50 interfaces that were extremely
>> weak bases to build on back when Syrup started, and that were chosen
>> as the point of integration with Evergreen, have firmed up
>> considerably since then (yes - we now accept and handle queries with
>> non-ASCII characters properly!). So there's that. But they're still
>> limited compared than their native Evergreen counterparts.
>
> I'm glad for the improved services. But I don't think we've painted
> ourselves into a SIP and Z39.50 corner. They're supported, but I've
> tried to isolate them as implementation details and keep the lookup
> services as abstract as possible. (It's still a work in progress, not
> a work of beauty!) There are already OpenSRF calls in our current
> codebase for barcode-lookup calls, because SIP is insufficient. (We
> also have some hackish support for integration with the OPAC
> through bookbag URLs and such.)
Good to hear. And I would say much of it is indeed beautful!
> I guess my big question is: how much happier would you be if the Syrup
> data were in an Evergreen database proper?
Much. If it's a single schema with columns denotating the related
libraries, then I think we can even model it in Evergreen's
fieldmapper IDL and get direct access to it for reporting purposes /
building more applications on top of.
> Robin's proposed schema is
> a good starting point for discussion, since he relates the reserves
> schema to the EG schemas, and we've already invested some effort
> together to consider how we'd do that integration.
>
> We can't transmute Python into Perl, but I think the other issues are
> surmountable. Where does that leave us?
I think a lot of my concerns would be addressed by a tighter
integration with Evergreen; having the schema exist as an extension to
the Evergreen schema would be a huge step. Thanks for your thoughtful
response!
>
>> Robin - to make your proposal more concrete, can you model how a
>> typical reserves task would send and receive data between Syrup and
>> Evergreen? For example, a professor wants to place an item on
>> reserve for their course, starting next term. How do they do this,
>> and how does the item get from wherever it currently is to the
>> reserves location at the appropriate time, with a new temporary
>> circulation modifier, and with a new temporary call number? And
>> then, when the course is done, how does it get back to the correct
>> location with the previous circ modifier and call number? I think
>> working through something like this, with a description of the
>> actions humans have to take as well as identifying which OpenSRF
>> calls we would have to make (and where data is changing in both
>> Syrup and Evergreen), would be helpful.
I still think walking through scenarios like these would be useful for
ensuring that we've filed off the worst of the pain points in
accomplishing the tasks involved with reserves.
robin
Syrup project? I was initially under the impression that it was to
create a reserves system for Evergreen. With that in mind, I produced
the "Evergreen is the ILS" schema I posted. But after posting, I've
been made aware that the project isn't as dedicated to evergreen as I
thought -- as its been pointed out, there are people active on the
list that aren't from Evergreen libraries. So I figured I'd made an
incorrect assumption and the project was to create a standalone
reserves product that would use Evergeen as it's first major ILS
binding.
So I guess my questions are:
What's the goal of this project?
I've only seen syrup discussed in an Evergreen context, so why did the
standalone aspect ever come up? (there must be some reason for it).
I was hoping to work on reserves this weekend, so it would be great if
we could sort this today.
cheers,
Robin
PS
For my own part, I believe the best products:
1) are tightly coupled
2) start with the data and work up from there
3) leverage a few technologies well and in-depth, rather then using a
lot of different ones
On Jan 22, 10:19 am, Dan Scott <deni...@gmail.com> wrote:
> 2010/1/22 Art W Rhyno <artrh...@uwindsor.ca>:
robin
we've got two separate projects here: one to develop a reserves system
for Evergreen, and one to build a standalone product to be used for
other ILSs.
thoughts?
robin
Art W Rhyno
>we could sort this today.
Syrup came out of a meeting in the Fall of 2008 when the Conifer partners met and one of the partners felt strongly that reserves should be the number one priority for development (ironically, not any of the organizations in the discussion). Reserves Direct was considered but lacked internationalization and seemed to be a defunct project. Graham was willing to help us out and django became the path because it could draw on his strengths, Graham is way too modest but he is a very deep and gifted python programmer, the only person I have ever seen as pythonic in nature is Dan Chudnov. Anyway, then, as in now, we were very short of resources and the world belonged to whatever we could tap into. If someone had come forward with Cobol skills, then that might have been the direction. Evergreen already brings together a breathtaking combination of technologies, I don't think django really falls that far out of place here given the postgres orientation and the opensrf support in python. The dojo/jquery layer is a very thin consideration in syrup since syrup is very light on javascript and any that is used is largely declarative and strictly for UI purposes. Plus, I didn't realize pylons had been dropped along the way but it was in the mix then and I was sort of in the "well if Bill likes this pythony framework approach, then it must have something going for it" ever since his Code4Lib 2008 posting [1].
Nuts, I gotta run here, ok, bullet point form switchover:
* we can switch directions at any time if we can resource the pursuit of other paths, we are relying a lot on the good graces of others to make things happen and volunteer spaces are by nature highly constrained
* syrup has a lot in it, Graham has a background in courseware and my wife and business partner is a former professor, so both she and my university age brood weighed in on what they wanted to see, syrup might be slanted particular ways but we gave any interested voice a lot of volume, maybe those voices were too familiar but this was all squeezed into lots of other projects (Graham has probably posted 10 words for every 1 that has come through the list and directly, the bidirection flows may be infrequent but have had high fidelity when they occurred)
* e-reserves is completely decoupled at Windsor with docutek, syrup would actually be far more integrated than what we have now
* trust me, you don't want me to ever code in C and perl again in my natural life, I lost those chops some time around when the Berlin Wall fell
* syrup can do a lot with ldap course integration, then is an important direction for campuses with growing directory services
* upei seemed happy with bookbags for physical reserves, to me this was/is the working solution for allowing the space for a more full featured application
The main message is to look at what's there already in syrup. SIP and Z39.50 had a fair amount of attention, the support for uploading and managing electronic objects is quite strong, and opensrf is a fully realized layer which, after all:
"I could go on gushing for hours about how cool OpenSRF is, and how, because of it’s support of (and in fact insistence on) decoupled, simple, layered services, it has the power to make the world a better place " [2]
Amen, I still think opensrf is to the ILS what http is to the web, and syrup reflects that viewpoint. The other aspect is that I think we had/have some hope that we might get support from those using Reserves Direct and need an exit strategy at some point. Anyway, I don't see fleshing out better support for reserves beyond bookbags as a problem, e-reserves are a big deal for us but maybe that could be syrup's role if it's not the whole enchilada.
Make sense? I have my cell with me if you want to give me a call. Before 5 pm or after midnight I won't have to yell over electric guitars and drums.
art
---
1. http://www.open-ils.org/blog/?p=125
2. http://open-ils.org/blog/?p=40
robin
Sorry this is all over you while you're on the road, I forgot you were
away and I shouldn't have been so insistent about having this
conversation right now.
Well, I get it. Sounds like all the right decisions under the
circumstances. In my last post I said I think we have two separate
projects here, and I do -- they both have a lot of merit and I don't
think one needs to "win" over the other. I think a lot of cross-
pollination could happen here if both projects proceed on parallel
paths. I could really learn some stuff by looking at syrups e-
reserves stuff (I don't even know where to start with that stuff).
I'm happy to proceed with a more Evergreen centric approach, helping
out when I can with syrup (which I'm still interested in), sharing any
revelations about reserves in general as things proceed.
My two cents...
robin
> because of it?s support of (and in fact insistence on) decoupled, simple,
Art W Rhyno
http://comet.cs.uoguelph.ca/syrupowa/
I will flesh out some more course examples tomorrow.
art