It's almost the end of 2012, and I couldn't let it pass as a blog-free year!
In January, I released the first MinimServer beta. I'd been working on it for a few months, and I wanted to see if it would be as interesting and useful to other people as it was to me. After my previous experience with JStreamer, I didn't set my expectations too high. I decided to set a goal of having at least 100 users to consider MinimServer as a success and worth continuing, and I had prepared myself for not achieving that goal and moving on to other things.
I think that number of users was reached in the first few months, though it's hard to measure how many active users there are. Based on downloads and user feedback (forum posts), MinimServer probably has a few hundred active users now. This has kept me busier than I could ever have imagined, doing everything from requirements analysis, architecture, design, development, test, build, webmaster, user support and bug fixing. I've used an open development model, with lots of discussion about what new features should be added and how they should be implemented. I haven't made the code open source, mainly because I'm enjoying having the opportunity to make MinimServer what I think it should be, without the inevitable compromises that would arise from having multiple developers with different perspectives on how things should be done.
Looking forward to 2013, I've spent the last few weeks integrating my earlier JStreamer work with MinimServer. The combination should provide some interesting real-world uses for this audio streaming technology that I developed in JStreamer. The result will be launched in the next month or two, and will extend MinimServer by providing support for network streaming as well as streaming from a local server. The world of digital audio is heading rapidly in this direction, and I'm hoping to bring a few innovations to the network streaming party!
There has been a bit of time for other things this year as well as working on MinimServer. We've been to Pembrokeshire, the Lake District, Northumberland and Normandy, and I was very lucky to get a ticket for the memorable "Super Saturday" in the Olympic Stadium.
With all best wishes for a happy, healthy and successful 2013,
Simon
Monday, 31 December 2012
Monday, 8 August 2011
jMinim
For various reasons I haven't taken JStreamer much further in the last few months. I had a few users of the beta release, but shortly afterwards the BBC fixed their problem with Radio 3 online broadcasting, which removed the major use case that had motivated user interest in JStreamer.
The other problem with JStreamer was its lack of integration with UPnP AV, the industry standard for home media networking. Fixing this would be a (not so) small matter of programming. Of course, if I could find an open-source Java implementation of UPnP AV, I would be able to use that instead of rolling my own.
Well, what you wish for does sometimes turn out to be what you get, and the nice people at Linn Products have just released such a thing as part of the OpenHome project under the catchy name of ohNet. (I think that's pronounced O-H-Net.) I've been looking at this over the last few days and it seems to be just what I need. It's not pure Java, but life is never quite perfect. Instead, it's C++ code with Java bindings implemented using JNI, which makes for some entertaining debugging sessions using Visual Studio to track down 0xC0000005 access violations (remember those?)
I've tried running the tests (and found a bug or two), but it's much more satisfying and motivating to build something useful. After much thought, I've decided that this useful something should be a functional UPnP AV / OpenHome stack consisting of a music server, music player, and control point, all written in Java. I'm aiming for "meets minimum" functionality initially, which could possibly be extended later depending on user reaction. After many hours searching for the very few music-related domain names that aren't already taken, I've settled on the name jMinim for the project (minim[al functionality] / minim==musical note) with the three components named MinimServer, MinimPlayer, and MinimControl. The web sites are up and running: see jminim.org, minimserver.com, minimplayer.com, and minimcontrol.com for what little information is currently available.
The other problem with JStreamer was its lack of integration with UPnP AV, the industry standard for home media networking. Fixing this would be a (not so) small matter of programming. Of course, if I could find an open-source Java implementation of UPnP AV, I would be able to use that instead of rolling my own.
Well, what you wish for does sometimes turn out to be what you get, and the nice people at Linn Products have just released such a thing as part of the OpenHome project under the catchy name of ohNet. (I think that's pronounced O-H-Net.) I've been looking at this over the last few days and it seems to be just what I need. It's not pure Java, but life is never quite perfect. Instead, it's C++ code with Java bindings implemented using JNI, which makes for some entertaining debugging sessions using Visual Studio to track down 0xC0000005 access violations (remember those?)
I've tried running the tests (and found a bug or two), but it's much more satisfying and motivating to build something useful. After much thought, I've decided that this useful something should be a functional UPnP AV / OpenHome stack consisting of a music server, music player, and control point, all written in Java. I'm aiming for "meets minimum" functionality initially, which could possibly be extended later depending on user reaction. After many hours searching for the very few music-related domain names that aren't already taken, I've settled on the name jMinim for the project (minim[al functionality] / minim==musical note) with the three components named MinimServer, MinimPlayer, and MinimControl. The web sites are up and running: see jminim.org, minimserver.com, minimplayer.com, and minimcontrol.com for what little information is currently available.
Sunday, 6 March 2011
The JStreamer Beta is available
I've been working on JStreamer (including the extremely crude prototype that preceded it) for about 6 months, and at last it's available as a beta release! I'm excited about this because it's the first software offering that's truly "mine" in the sense that I designed and developed it myself and I'm also the legal owner of the code.
The other thing that I've found exciting is that JStreamer has turned out really well. Most software has inevitable compromises with some parts having functional limitations or design trade-offs, or not being as easy to use as it ideally should be. To my great surprise, this hasn't happened with JStreamer. So far I have been able to add functionality and remove limitations with clean designs and no compromises, and there have been a number of "Yes it can" moments. Of course the real test will come when users try to do things that I haven't anticipated, and we'll see how well the design holds up then!
The other thing that I've found exciting is that JStreamer has turned out really well. Most software has inevitable compromises with some parts having functional limitations or design trade-offs, or not being as easy to use as it ideally should be. To my great surprise, this hasn't happened with JStreamer. So far I have been able to add functionality and remove limitations with clean designs and no compromises, and there have been a number of "Yes it can" moments. Of course the real test will come when users try to do things that I haven't anticipated, and we'll see how well the design holds up then!
Friday, 18 February 2011
Tuscany SCA in Action
It's been far too long since my last blog entry. I'll skip the excuses (mostly because there aren't any good ones!) and get straight into the latest news.
The most significant (and very recent) piece of news is that my book Tuscany SCA in Action is now finished and published! It's taken a long time, and I think the effort was worth it. You can take a look for yourself by following the above link to the publisher's website. If you like what you see, please buy a copy!
I'm one of five co-authors, and at first I thought that this would get my name on the cover with only 20% of the usual amount of work needed to write a book. That impression didn't last for long! Because of all the cross-reviewing/coordination/discussions/revision that was involved, I think I ended up doing more like 60%, of which 20% was the actual writing and 40% was everything else. The project also look a lot longer than I expected, with various stages of external review/comment/rework, followed by the production stage of proof reading and typesetting which stretched over many months. I learned a lot from doing it, and I'm pleased with the finished result.
I'm still involved with the Apache Tuscany project, and I was very pleased to be elected as a member of the Apache Software Foundation last summer. Tuscany is continuing to attract new users and I'm happy to be able to help users and continue to contribute towards the project's success.
When I retired I decided that I wanted to do something else in a different area of technology, but I wasn't sure exactly what it would be. I've always been interested in music, and recent developments in digital music technology have attracted my attention. After I retired I bought a Linn DS digital stream music player (see this link) and I started learning about digital music and streaming technology. It's been a fascinating voyage of discovery that reminds me of the early days of PCs with many competing formats and standards, and rapid advances in the state of the art. The other aspect that interests me is that there are still many gaps in making the various products and technologies join up to do what the listener wants in a simple and convenient manner. Well, gaps are there to be filled, and for the last few months I've been working on doing just that. For more information about my current project, take a look at jstreamer.com. I'm excited about this because it brings my experience of building extensible software frameworks to the world of streaming audio, which at some level isn't vastly different from any other kind of client/server network protocol. That's probably enough on this topic for now (I could go on for pages!), so I'll save the rest for future blog entries here. I'm intending to make these entries much more regular than they have been up to now.
In case you're interested in the big topic from my last blog entry, the tree stumps are long gone and have been replaced by two raised beds for growing vegetables and fruit, together with a fairly large expanse of bare ground which seems to be much liked by the local weed population. This year I'll need to do something about that. One area is earmarked for planting a tree (of suitable size!), another area will be used for a "feature" (exact specification TBD), and we'll get a few plants to fill the remainder. I thought about planting a few vines, but there isn't quite enough space for that.
A year ago I was in New Zealand enjoying wonderful uncrowded scenery, Kiwi hospitality and friendliness, and the Southern Hemisphere summer! Those memories are still fresh and precious and I hope they will never fade. My wife Charlotte wrote a blog while we were there, and if you're interested you can see something of our travels at charlottejnash.blogspot.com.
The most significant (and very recent) piece of news is that my book Tuscany SCA in Action is now finished and published! It's taken a long time, and I think the effort was worth it. You can take a look for yourself by following the above link to the publisher's website. If you like what you see, please buy a copy!
I'm one of five co-authors, and at first I thought that this would get my name on the cover with only 20% of the usual amount of work needed to write a book. That impression didn't last for long! Because of all the cross-reviewing/coordination/discussions/revision that was involved, I think I ended up doing more like 60%, of which 20% was the actual writing and 40% was everything else. The project also look a lot longer than I expected, with various stages of external review/comment/rework, followed by the production stage of proof reading and typesetting which stretched over many months. I learned a lot from doing it, and I'm pleased with the finished result.
I'm still involved with the Apache Tuscany project, and I was very pleased to be elected as a member of the Apache Software Foundation last summer. Tuscany is continuing to attract new users and I'm happy to be able to help users and continue to contribute towards the project's success.
When I retired I decided that I wanted to do something else in a different area of technology, but I wasn't sure exactly what it would be. I've always been interested in music, and recent developments in digital music technology have attracted my attention. After I retired I bought a Linn DS digital stream music player (see this link) and I started learning about digital music and streaming technology. It's been a fascinating voyage of discovery that reminds me of the early days of PCs with many competing formats and standards, and rapid advances in the state of the art. The other aspect that interests me is that there are still many gaps in making the various products and technologies join up to do what the listener wants in a simple and convenient manner. Well, gaps are there to be filled, and for the last few months I've been working on doing just that. For more information about my current project, take a look at jstreamer.com. I'm excited about this because it brings my experience of building extensible software frameworks to the world of streaming audio, which at some level isn't vastly different from any other kind of client/server network protocol. That's probably enough on this topic for now (I could go on for pages!), so I'll save the rest for future blog entries here. I'm intending to make these entries much more regular than they have been up to now.
In case you're interested in the big topic from my last blog entry, the tree stumps are long gone and have been replaced by two raised beds for growing vegetables and fruit, together with a fairly large expanse of bare ground which seems to be much liked by the local weed population. This year I'll need to do something about that. One area is earmarked for planting a tree (of suitable size!), another area will be used for a "feature" (exact specification TBD), and we'll get a few plants to fill the remainder. I thought about planting a few vines, but there isn't quite enough space for that.
A year ago I was in New Zealand enjoying wonderful uncrowded scenery, Kiwi hospitality and friendliness, and the Southern Hemisphere summer! Those memories are still fresh and precious and I hope they will never fade. My wife Charlotte wrote a blog while we were there, and if you're interested you can see something of our travels at charlottejnash.blogspot.com.
Thursday, 8 January 2009
Happy New Year!
It's just over 3 months since my retirement, and time has passed quickly. I'm still enjoying it, and I haven't had a moment's regret for my decision to retire. The start of 2009 seems like a good time to take stock of my experiences of retired life so far.
Some things have changed a lot for me since I retired, but the basics of life are still the same. For example, I have good days and not so good days, just like I had at work. The good days are mostly when I feel I have accomplished something. The more tangible and physical the accomplishment is (i.e., not mainly involving time spent in front of a computer), the better.
Top of the list so far of "feel good" accomplishments was completing phase 1 of the Great Tree Stump Project by ripping the first enormous stump out of the ground, after having spent months patiently encircling it and removing its roots (also enormous) one by one with a combination of electric and hand sawing. The key to success is to move enough earth away from the root so that it's completely exposed with daylight underneath. For my enormous stump and enormous roots, this involved digging down very deep and moving a large amount of earth, which needs a fairly large area where the earth can be placed. I discovered by experience that this process needs careful planning so that the earth receiving area is cleared and prepared first, before even starting the encircling and sawing campaign on the stump's roots.
The two stumps I'm removing are in an area of my garden that was once a flower bed but has become completely overrun by weeds, including extensive infestations of bindweed and ivy. The stump removal is part of a larger project to reinstate this area to its original purpose. I'm removing the weeds by digging them out completely by hand, so the earth moving for stump removal purposes has the nice side benefit of enabling me to remove the weeds at the same time. As well as the weeds, the soil is full of very large stones, which I am removing as I go and placing them in rubble sacks filled to the maximum weight that I can lift. I have filled about 20 of these sacks so far, and I'm expecting to have between 25 and 30 when the project is finished. This doesn't include the largest and most attractive flints, which have been separated out for future use in building a rockery on part of the area that's being cleared.
Progress has been slow over the last few weeks because of the wet and cold winter weather and the very limited hours of daylight. Despite this, I have cleared around 80% of the total area and I am about 60% through the encircling campaign on the second stump. The final completion will be announced here and celebrated in a suitable manner!
In my next blog post I'll say more about the other things currently occupying my time and attention. I'll also talk about whether retirement (and life) should be more about "doing" (tree stumps, etc.) or about "being".
It only remains for me to wish you all a healthy and happy New Year! Part of the joy of blogging is that I don't know who will be reading this. I used to be somewhat concerned about this and it made me feel rather inhibited, but now I'm beginning to see it much more as an opportunity. I know I have at least a few readers, from the comments to my last post. Thanks for your kind words, and keep those comments coming!
Some things have changed a lot for me since I retired, but the basics of life are still the same. For example, I have good days and not so good days, just like I had at work. The good days are mostly when I feel I have accomplished something. The more tangible and physical the accomplishment is (i.e., not mainly involving time spent in front of a computer), the better.
Top of the list so far of "feel good" accomplishments was completing phase 1 of the Great Tree Stump Project by ripping the first enormous stump out of the ground, after having spent months patiently encircling it and removing its roots (also enormous) one by one with a combination of electric and hand sawing. The key to success is to move enough earth away from the root so that it's completely exposed with daylight underneath. For my enormous stump and enormous roots, this involved digging down very deep and moving a large amount of earth, which needs a fairly large area where the earth can be placed. I discovered by experience that this process needs careful planning so that the earth receiving area is cleared and prepared first, before even starting the encircling and sawing campaign on the stump's roots.
The two stumps I'm removing are in an area of my garden that was once a flower bed but has become completely overrun by weeds, including extensive infestations of bindweed and ivy. The stump removal is part of a larger project to reinstate this area to its original purpose. I'm removing the weeds by digging them out completely by hand, so the earth moving for stump removal purposes has the nice side benefit of enabling me to remove the weeds at the same time. As well as the weeds, the soil is full of very large stones, which I am removing as I go and placing them in rubble sacks filled to the maximum weight that I can lift. I have filled about 20 of these sacks so far, and I'm expecting to have between 25 and 30 when the project is finished. This doesn't include the largest and most attractive flints, which have been separated out for future use in building a rockery on part of the area that's being cleared.
Progress has been slow over the last few weeks because of the wet and cold winter weather and the very limited hours of daylight. Despite this, I have cleared around 80% of the total area and I am about 60% through the encircling campaign on the second stump. The final completion will be announced here and celebrated in a suitable manner!
In my next blog post I'll say more about the other things currently occupying my time and attention. I'll also talk about whether retirement (and life) should be more about "doing" (tree stumps, etc.) or about "being".
It only remains for me to wish you all a healthy and happy New Year! Part of the joy of blogging is that I don't know who will be reading this. I used to be somewhat concerned about this and it made me feel rather inhibited, but now I'm beginning to see it much more as an opportunity. I know I have at least a few readers, from the comments to my last post. Thanks for your kind words, and keep those comments coming!
Sunday, 5 October 2008
Retiring!
Today is my official last day as an IBM employee. I am retiring after 34 years with IBM, which according to my calculations is around 61% of my life! I've had a great time at IBM, and I have enjoyed the opportunity to do many interesting and satisfying things. The best part has been the relationships I have developed with people I have worked with over the years, many of whom have become close colleagues and friends. My IBM career has been an exciting ride with some wonderful experiences, and now it's the right time for me to move on to the next stage of my life with a different work/life balance and more time for personal and family things.
I'm not completely giving up technical work. I'll still be active as a Tuscany committer and in the SCA standardization work at OASIS. I'm also co-authoring a book on Tuscany. I'll post updates here as the project progresses.
I have made some resolutions for my retirement. One is to go for a walk first thing after breakfast every weekday. I've been doing this for the last 3 weeks when I've been on pre-retirement vacation, and I'm really enjoying it. As well as making me fitter, I'm finding it really good to have some time to think about the things I want to do that day. Thinking while walking seems to be a good combination for me.
Another resolution is to write more of these blog entries! I'm not quite sure how this one will turn out. It takes more effort for me to write a blog entry than go for a walk, but maybe that will change with more practice. My thoughts at the moment are to talk about various things that are occupying me at the moment. These might be technical topics related to Tuscany or SCA, other computer-related matters like my experiences with networked printing at home, or things that have nothing to do with computers such as the Great Tree Stump Project. More about that another day...
I'm not completely giving up technical work. I'll still be active as a Tuscany committer and in the SCA standardization work at OASIS. I'm also co-authoring a book on Tuscany. I'll post updates here as the project progresses.
I have made some resolutions for my retirement. One is to go for a walk first thing after breakfast every weekday. I've been doing this for the last 3 weeks when I've been on pre-retirement vacation, and I'm really enjoying it. As well as making me fitter, I'm finding it really good to have some time to think about the things I want to do that day. Thinking while walking seems to be a good combination for me.
Another resolution is to write more of these blog entries! I'm not quite sure how this one will turn out. It takes more effort for me to write a blog entry than go for a walk, but maybe that will change with more practice. My thoughts at the moment are to talk about various things that are occupying me at the moment. These might be technical topics related to Tuscany or SCA, other computer-related matters like my experiences with networked printing at home, or things that have nothing to do with computers such as the Great Tree Stump Project. More about that another day...
Friday, 8 June 2007
SCA: flexible, extensible, and useful for ordering a beer
This is my first ever blog post so I'd like to start by introducing myself. I'm a member of the Apache Tuscany developer community and I've been involved with Tuscany since the project started in 2005. I'm also an IBM Distinguished Engineer and I have worked on so many software development projects over my career that you really don't want the complete list (trust me). I'll just mention two of these into which I put an especially large dose of myself, with rather different results: RMI-IIOP, which brought together Java RMI and CORBA, became part of the Java platform, and is used by every JEE application server; and Object Rexx, which broke new ground technically for object-oriented scripting languages, but never achieved its full commercial potential for various reasons including the success of Java.
My passion these days is for Service Component Architecture (SCA) and I have started this blog to give my perspective on SCA and explain why it is an important step forward for building distributed applications in a service-oriented style. The views I'll express here are my personal opinions and don't necessarily represent IBM's positions.
Others (Dave Chappell here, Mike Rowley here, Sanjay Patil here, and Steve Kinder here) have expressed their views on whether SCA is a new programming model or not. For me the main value of SCA is not the programming model "in the small" (whether new or not new), but rather that SCA provides a common framework for bringing together assets from a wide range of technologies to create a solution that delivers business value. This isn't a new concept (remember CORBA?), but SCA puts a different spin on it with a framework that's designed for extensibility and isn't prescriptive about using any particular underlying technology. SCA strikes the delicate balance between defining a consistent set of common high-level SOA concepts and being flexible about how these concepts are rendered into different implementation environments that participate in the SCA ecosystem.
CORBA specified IDL for interface definitions and IIOP for the wire protocol. To come to the CORBA party, you needed to be able to define your interfaces using IDL and speak IIOP on the wire. RMI defined its interfaces using Java and spoke the JRMP protocol on the wire, so RMI-IIOP was created to allow RMI to become part of the CORBA ecosystem. With SCA, this uniformity of interface definitions and wire protocols isn't required. The architectural constructs that SCA defines (services, components, references, bindings, interfaces, implementations, composites, wires, policy intents) are designed to be flexible and extensible so that different SCA implementations can render them in different ways into the lower-level specifics of that implementation.
These renderings could differ significantly for different implementation technologies. The SCA 1.0 specs define renderings for Java, BPEL, Spring and C++ as implementation types, and Web services, JMS and EJB as protocol bindings. This set will grow in the future, but SCA usage doesn't need to be bounded by what the spec supports. There's a PHP implementation of SCA, providing a rendering that makes sense in a lightweight scripting environment. The scripting theme also surfaces in Apache Tuscany, which provides SCA renderings for various scripting languages including Ruby, Python, JavaScript and Groovy, as well as the more mainstream support for Java, Spring and C++ that's defined by the SCA specs. In the last week I've seen interest in implementing SCA support for OSGi, and having XSLT transformations as SCA implementations. You can think of SCA as a "lingua franca" for SOA that brings all these technologies together, not at a low level of interface definitions and wire protocols, but at a higher level of assembling, composing and customizing services.
What if some implementations only provide a partial rendering of SCA? Is this OK, or should SCA insist on a strictly defined minimum set of capabilities that everyone needs in order to come to SCA's party? The discussion on this will get going at OASIS soon (the SCA 1.0 specifications don't specify compliance points), so there's no official SCA position on this yet. I understand the value of uniformity and tight specifications, but I'm inclined to think that SCA shouldn't be too rigid and prescriptive about this. Imagine two people talking in a natural language such as English or French, who aren't native speakers and have an imperfect grasp of the language they are using, but can still communicate well enough to get by in their conversation. I was in Italy some years ago trying find a particular village, getting lost on back roads in deepest rural Tuscany, and trying to ask directions from an Italian man who spoke no English. My Italian is pretty bad too (I can manage "una birra, per favore"), and despite best efforts on both sides, it just wasn't going to work. My wife had a brainwave and started talking to the man in French. Success! The Italian man and my English wife both spoke enough French to ask for and receive the directions. Applying this to SCA, if different environments speak different dialects or subsets of SCA, there needs to be enough overlap and mutual understanding to "get by" for some business purpose, but how much shared vocabulary is needed will depend on the particular needs of the services involved. Some environments will provide a full implementation of SCA (fluent native speakers), and others will have just enough vocabulary and grammar to be able to order a beer. More fluency is always better, but let's also remember the greatest values that SCA has to offer: its flexibility, extensibility, and inclusivity.
My passion these days is for Service Component Architecture (SCA) and I have started this blog to give my perspective on SCA and explain why it is an important step forward for building distributed applications in a service-oriented style. The views I'll express here are my personal opinions and don't necessarily represent IBM's positions.
Others (Dave Chappell here, Mike Rowley here, Sanjay Patil here, and Steve Kinder here) have expressed their views on whether SCA is a new programming model or not. For me the main value of SCA is not the programming model "in the small" (whether new or not new), but rather that SCA provides a common framework for bringing together assets from a wide range of technologies to create a solution that delivers business value. This isn't a new concept (remember CORBA?), but SCA puts a different spin on it with a framework that's designed for extensibility and isn't prescriptive about using any particular underlying technology. SCA strikes the delicate balance between defining a consistent set of common high-level SOA concepts and being flexible about how these concepts are rendered into different implementation environments that participate in the SCA ecosystem.
CORBA specified IDL for interface definitions and IIOP for the wire protocol. To come to the CORBA party, you needed to be able to define your interfaces using IDL and speak IIOP on the wire. RMI defined its interfaces using Java and spoke the JRMP protocol on the wire, so RMI-IIOP was created to allow RMI to become part of the CORBA ecosystem. With SCA, this uniformity of interface definitions and wire protocols isn't required. The architectural constructs that SCA defines (services, components, references, bindings, interfaces, implementations, composites, wires, policy intents) are designed to be flexible and extensible so that different SCA implementations can render them in different ways into the lower-level specifics of that implementation.
These renderings could differ significantly for different implementation technologies. The SCA 1.0 specs define renderings for Java, BPEL, Spring and C++ as implementation types, and Web services, JMS and EJB as protocol bindings. This set will grow in the future, but SCA usage doesn't need to be bounded by what the spec supports. There's a PHP implementation of SCA, providing a rendering that makes sense in a lightweight scripting environment. The scripting theme also surfaces in Apache Tuscany, which provides SCA renderings for various scripting languages including Ruby, Python, JavaScript and Groovy, as well as the more mainstream support for Java, Spring and C++ that's defined by the SCA specs. In the last week I've seen interest in implementing SCA support for OSGi, and having XSLT transformations as SCA implementations. You can think of SCA as a "lingua franca" for SOA that brings all these technologies together, not at a low level of interface definitions and wire protocols, but at a higher level of assembling, composing and customizing services.
What if some implementations only provide a partial rendering of SCA? Is this OK, or should SCA insist on a strictly defined minimum set of capabilities that everyone needs in order to come to SCA's party? The discussion on this will get going at OASIS soon (the SCA 1.0 specifications don't specify compliance points), so there's no official SCA position on this yet. I understand the value of uniformity and tight specifications, but I'm inclined to think that SCA shouldn't be too rigid and prescriptive about this. Imagine two people talking in a natural language such as English or French, who aren't native speakers and have an imperfect grasp of the language they are using, but can still communicate well enough to get by in their conversation. I was in Italy some years ago trying find a particular village, getting lost on back roads in deepest rural Tuscany, and trying to ask directions from an Italian man who spoke no English. My Italian is pretty bad too (I can manage "una birra, per favore"), and despite best efforts on both sides, it just wasn't going to work. My wife had a brainwave and started talking to the man in French. Success! The Italian man and my English wife both spoke enough French to ask for and receive the directions. Applying this to SCA, if different environments speak different dialects or subsets of SCA, there needs to be enough overlap and mutual understanding to "get by" for some business purpose, but how much shared vocabulary is needed will depend on the particular needs of the services involved. Some environments will provide a full implementation of SCA (fluent native speakers), and others will have just enough vocabulary and grammar to be able to order a beer. More fluency is always better, but let's also remember the greatest values that SCA has to offer: its flexibility, extensibility, and inclusivity.
Subscribe to:
Posts (Atom)
